(Proporcjonalna) opłata pobierana w systemie IN-OUT za podróż lub odcinek podróży przy wsiadaniu, która może być pobierana w przypadkach, gdy obciążenie jest dokonywane z góry z pamięci jednostki wartości transportu publicznego lub płacone bezpośrednio za pomocą portfela elektronicznego.

Administrator ASP to osoba zarejestrowana u dostawcy usług bezpieczeństwa (TSI) jako kontakt administracyjny w systemie KM i PKI organizacji. ASP administratora jest specjalizacją ASP użytkownika, ponieważ ma dodatkowe uprawnienia administracyjne, tj. może tworzyć i blokować ASP użytkownika.

Aplikacja transportu publicznego jest zwykle aktywowana na nośniku użytkownika bezpośrednio po wydaniu nośnika klientowi. W tym celu status aplikacji jest ustawiany na aktywny za pomocą transakcji wyjściowej, wprowadzany jest okres ważności i inicjowany jest licznik zmian statusu. Aplikacja może być następnie używana przez klienta.

Czyszczenie bazy danych zarządzania działaniami; usuwa to zlecenia działań, które zostały już wykonane w celu wydania, odblokowania lub anulowania z bazy danych listy działań w systemie listy działań właściciela produktu, dla których właściciel produktu (PV) otrzymał dowód kontroli lub zablokowania, ale nie oczekiwany dowód (dowód wydania lub dowód odblokowania). W takim przypadku należy również poinformować partnera umowy klienta, który zlecił to działanie.

Lista działań to lista działań, które należy wykonać na terminalu akceptacyjnym przy następnym kontakcie z nośnikiem użytkownika. Jest ona dostarczana przez system właściciela produktu, pobierana przez partnerów wykonujących umowę z klientem, a następnie dystrybuowana do ich terminali akceptacji.

Zarządzanie działaniami jest jednostką administracyjną w systemach zlecającego partnera umowy klienta, wykonującego partnera umowy klienta i właściciela produktu. Działania są konkretnymi elementami do wykonania, które zazwyczaj muszą być dostarczone w formie listy działań i podlegają cyklowi życia (dlatego muszą być zarządzane).

Usługa listy działań jest oferowana przez system właściciela produktu. Za pośrednictwem tej usługi systemy partnerów wykonujących umowy z klientami pobierają listy działań i dystrybuują je do swoich terminali. Z drugiej strony, zlecający partnerzy klienta mogą zamawiać działania od właściciela produktu, który umieszcza je na liście działań właściciela produktu.

Całość technologii urządzenia (sprzęt i oprogramowanie), która umożliwia wymianę danych z nośnikiem użytkownika (ISO/IEC 14443). Są to

• Urządzenia do tworzenia kompletnych biletów (na chipie i/lub papierze)
• Urządzenia do tworzenia i/lub uzupełniania biletów
• urządzenia do pobierania informacji i drukowania biletów i kuponów/pokwitowań
• Urządzenia do ładowania jednostek wartości w transporcie publicznym
• Urządzenia mobilne do sprawdzania i/lub walidacji biletów
• Urządzenia do aktywacji i personalizacji aplikacji.

Rozróżnia się warianty systemu z ręcznym wstępnym wyborem zakupu biletu i systemem IN-OUT.

Aplikacja składa się z danych, poleceń, procesów, stanów, mechanizmów, algorytmów i kodu programu, np. na karcie inteligentnej lub smartfonie, w celu jej obsługi w określonym systemie. Mechanizmy te obejmują integrację z architekturą bezpieczeństwa danego całego systemu, a także protokoły transmisji kart chipowych.

Wydawca aplikacji (AH) posiada umowę na korzystanie z aplikacji transportu publicznego. Zezwala on na odsprzedaż aplikacji przez partnera klienta klientowi. Definiuje zasady aplikacji i przyznaje właścicielowi produktu, partnerowi umowy z klientem i dostawcy usług prawo do uczestnictwa w systemach EFM, zapewnia im niezbędne identyfikatory i przyznaje prawo do korzystania z kluczy wydawcy aplikacji. Upoważnia partnerów kontraktowych klienta do wydawania aplikacji na nośniku użytkownika. Ponadto jest odpowiedzialny za dostarczanie informacji o identyfikatorze instancji aplikacji (identyfikuje nośnik użytkownika) w przypadku zapytań dotyczących wadliwych nośników użytkownika. Wydawca aplikacji wdraża zarządzanie cyklem życia dla wszystkich instancji aplikacji.

Identyfikator aplikacji

Identyfikator aplikacji znajdującej się na nośniku użytkownika. Ponieważ na przykład na karcie chipowej może istnieć kilka aplikacji, identyfikator służy do wyboru właściwej aplikacji (w tym przypadku aplikacji transportu publicznego).

Narzędzie ASM

Narzędzie ASM (Application and Security Management Tool) jest centralnym systemem usług i administracji dla (((eTicket Germany. Obsługuje ono główne zadania menedżera schematu zarządzania aplikacjami i bezpieczeństwem w (((eTicket Germany, takie jak

- Portal usługowy do rejestracji w (((eTicket Germany

- Obsługa klienta dla firm transportowych i producentów

- Administracja klientami, producentami i uczestnikami (((eTicket

Germany

- Dostarczanie dokumentów KA

- Zamawianie komponentów bezpieczeństwa KA, przetwarzanie i sprawdzanie zamówień

oraz część procesów monitorowania bezpieczeństwa

i reprezentuje system referencyjny KA wystawcy aplikacji (AHS).

Dostęp do narzędzia ASM można uzyskać za pośrednictwem strony https://asmtool.eticket-deutschland.de/asm-toolextern.

Kryptografia asymetryczna / Kryptografia asymetryczna

Asymetryczne metody kryptograficzne wykorzystują pary kluczy składające się z klucza publicznego i klucza prywatnego. Klucz publiczny nie jest tajny; powinien być znany jak największej liczbie innych użytkowników. Może być używany do wykonywania operacji publicznych, tj. szyfrowania wiadomości lub weryfikacji podpisów cyfrowych. Ważne jest, aby klucz publiczny mógł być jednoznacznie przypisany do użytkownika. Gwarantuje to certyfikat. Klucz prywatny jest wymagany do odszyfrowania zaszyfrowanego tekstu lub podpisania wiadomości. W przeciwieństwie do procedur symetrycznych, w których kilku użytkowników współdzieli klucz symetryczny, w procedurach asymetrycznych tylko jeden użytkownik posiada klucz prywatny (tajny). Ta okoliczność umożliwia jednoznaczne przypisanie podpisu do użytkownika.

Kontrahent wykonujący umowę z klientem

Partner wykonujący umowę z klientem (aKVP) autoryzuje wykonanie akcji za pomocą nośnika użytkownika na jednym ze swoich terminali. Aby to zrobić, musi być podłączony do usługi listy działań i zarządzania działaniami właściciela produktu za pośrednictwem list działań. Może on być również autoryzującym partnerem umowy klienta (bKVP).

Wydawanie aplikacji

Może istnieć kilka podmiotów, które są upoważnione przez wystawcę aplikacji do utworzenia aplikacji na nośniku użytkownika zgodnie z daną specyfikacją i/lub do aktywowania jej do użytku. Aplikacja może również zostać wydana za pośrednictwem działu sprzedaży. Odbywa się to zawsze za pośrednictwem partnera umowy z klientem. Aplikacja na nośniku użytkownika jest również określana jako aplikacja transportu publicznego.

Autoload

Z autoryzacją jednostki wartości: Automatyczne doładowanie uzgodnioną ilością jednostek wartości PT dla istniejącej umowy z klientem w zależności od spełnienia uzgodnionych w umowie kryteriów (np. osiągnięcia lub spadku poniżej kwoty minimalnej). Odbywa się to dla jednostek wartości PT przechowywanych na nośniku użytkownika na każdym terminalu akceptującym, który wykrywa, że minimalna kwota doładowania nie została osiągnięta i obsługuje funkcję autoload. Wszystkie kwoty doładowań są przekazywane do systemu zaplecza partnera umowy z klientem.

Dla kont przedpłaconych (((autoryzacja ePayment: W przypadku tak zwanej autoryzacji konta przedpłaconego zasilanego za pośrednictwem rachunku kredytowego klienta, doładowanie z konta klienta jest kontrolowane za pośrednictwem systemu zaplecza głównego partnera umowy z klientem.

Główny partner umowy z klientem jest odpowiedzialny za fakturowanie klienta i przeprowadza rozliczenie finansowe ze stroną, która zrealizowała doładowanie. Nie jest możliwe ręczne określenie ilości opcji autoryzacji transportu, które mają zostać doładowane.

Po automatycznym doładowaniu na koncie rozliczeniowym przechowywanym dla umowy z klientem dokonywany jest wpis obciążenia odpowiadający wartości doładowanych opcji autoryzacji podróży.

Automatyczna autoryzacja przejazdu / uprawnienie IN-OUT

Automatyczna autoryzacja przejazdów (AFB) uprawnia klienta do korzystania z usług transportu publicznego. Reguluje ono sposób, w jaki klient płaci za korzystanie z usługi. Warunkiem wstępnym korzystania z AFB jest istnienie (((autoryzacji płatności elektronicznych na nośniku użytkownika. AFB jest zatem rodzajem wykorzystania (((autoryzacji e-płatności. W trakcie korzystania z autoryzacji w ramach rejestrowania danych dotyczących wsiadania i wysiadania w systemach IN-OUT tworzony jest dowód usługi.

Cechą charakterystyczną AFB jest to, że określa ramy wykorzystania i obliczania opłaty za usługę. AFB są wydawane jako metoda płatności oparta na koncie z procedurami prepaid (PEB) lub postpaid (POB) w systemie zaplecza lub jako metoda płatności oparta na medium użytkownika (WEB, może być anonimowa) w systemach KA.

Identyfikator aplikacji znajdującej się na nośniku użytkownika. Ponieważ na przykład na karcie chipowej może istnieć kilka aplikacji, identyfikator służy do wyboru właściwej aplikacji (w tym przypadku transportu publicznego).

Narzędzie ASM (Application and Security Management Tool) jest centralnym systemem usług i administracji dla (((eTicket Germany. Obsługuje ono główne zadania Scheme Managera w zakresie zarządzania aplikacjami i bezpieczeństwem w (((eTicket Germany, takie jak

- Portal usługowy do rejestracji w (((eTicket Germany

- Obsługa klienta dla firm transportowych i producentów

- Administracja klientami, producentami i uczestnikami (((eTicket Germany

- Dostarczanie dokumentów KA

- Zamawianie komponentów bezpieczeństwa KA, przetwarzanie i sprawdzanie zamówień

oraz część procesów monitorowania bezpieczeństwa

i reprezentuje system referencyjny KA wystawcy aplikacji (AHS). Dostęp do narzędzia ASM można uzyskać pod adresem https://asmtool.eticket-deutschland.de/.

Asymetryczne metody kryptograficzne wykorzystują pary kluczy składające się z klucza publicznego i klucza prywatnego. Klucz publiczny nie jest tajny; powinien być znany jak największej liczbie innych użytkowników. Może być używany do wykonywania operacji publicznych, tj. szyfrowania wiadomości lub weryfikacji podpisów cyfrowych. Ważne jest, aby klucz publiczny mógł być jednoznacznie przypisany do użytkownika. Gwarantuje to certyfikat. Klucz prywatny jest wymagany do odszyfrowania zaszyfrowanego tekstu lub podpisania wiadomości. W przeciwieństwie do procedur symetrycznych, w których kilku użytkowników współdzieli klucz symetryczny, w procedurach asymetrycznych tylko jeden użytkownik posiada klucz prywatny (tajny). Ta okoliczność umożliwia jednoznaczne przypisanie podpisu do użytkownika.

Wykonujący umowę klient (aKVP) autoryzuje wykonanie akcji za pomocą nośnika użytkownika na jednym ze swoich terminali. Aby to zrobić, musi być połączony z usługą listy działań i zarządzaniem działaniami właściciela produktu za pośrednictwem list działań. Może on być również autoryzującym partnerem umowy klienta (bKVP).

Może istnieć kilka podmiotów, które są upoważnione przez wydawcę aplikacji do tworzenia aplikacji na nośniku użytkownika zgodnie z daną specyfikacją i/lub do aktywowania jej do użytku. Aplikacja może również zostać wydana za pośrednictwem działu sprzedaży. Odbywa się to zawsze za pośrednictwem partnera kontraktowego klienta. Aplikacja na nośniku użytkownika jest również określana jako aplikacja transportu publicznego.

Z autoryzacją jednostek wartości: Automatyczne doładowanie uzgodnioną ilością jednostek wartości PT dla istniejącej umowy z klientem w zależności od spełnienia uzgodnionych w umowie kryteriów (np. osiągnięcia lub spadku poniżej kwoty minimalnej). Odbywa się to dla jednostek wartości PT przechowywanych na nośniku użytkownika na każdym terminalu akceptującym, który wykrywa, że minimalna kwota doładowania nie została osiągnięta i obsługuje funkcję autoload. Wszystkie kwoty doładowań są przekazywane do systemu zaplecza partnera umowy z klientem.

Dla kont przedpłaconych (((autoryzacja ePayment: W przypadku tak zwanej autoryzacji konta przedpłaconego zasilanego za pośrednictwem rachunku kredytowego klienta, doładowanie z konta klienta jest kontrolowane za pośrednictwem systemu zaplecza głównego partnera umowy z klientem.

Główny partner umowy z klientem jest odpowiedzialny za fakturowanie klienta i przeprowadza rozliczenie finansowe ze stroną, która zrealizowała doładowanie. Nie jest możliwe ręczne określenie ilości opcji autoryzacji transportu, które mają zostać doładowane. Po automatycznym doładowaniu na koncie rozliczeniowym przechowywanym dla umowy z klientem dokonywany jest wpis obciążenia odpowiadający wartości doładowanych opcji autoryzacji podróży.

Automatyczna autoryzacja podróży (AFB) uprawnia klienta do korzystania z usług transportu publicznego. Reguluje ona sposób, w jaki klient płaci za korzystanie z usługi. Warunkiem wstępnym korzystania z AFB jest istnienie autoryzacji (((e-płatności na nośniku użytkownika. AFB jest zatem rodzajem wykorzystania (((autoryzacji e-płatności. W trakcie korzystania z autoryzacji w ramach rejestrowania danych dotyczących wsiadania i wysiadania w systemach IN-OUT tworzony jest dowód usługi.

Cechą charakterystyczną AFB jest to, że określa ramy wykorzystania i obliczania opłaty za usługę. AFB są wydawane jako metoda płatności oparta na koncie z procedurami prepaid (PEB) lub postpaid (POB) w systemie zaplecza lub jako metoda płatności oparta na medium użytkownika (WEB, może być anonimowa) w systemach KA.

Autoryzacja opiera się na danych przechowywanych w aplikacji, która zezwala na korzystanie z usług transportu publicznego. Autoryzacja składa się między innymi z niepowtarzalnego identyfikatora i okresu ważności. Dane przechowywane w aplikacji mogą mieć postać biletu elektronicznego lub autoryzacji płatności elektronicznych. Bilet elektroniczny reprezentuje autoryzację w sensie autoryzacji podróży.

Autoryzacja płatności elektronicznych wykorzystuje te same struktury danych na nośniku użytkownika, ale nie jest jeszcze autoryzacją podróży, a jedynie podstawą i warunkiem wstępnym do wykorzystania w systemach IN-OUT (i może być tam wykorzystywana jako automatyczna autoryzacja podróży (AFB)). Rzeczywiste zezwolenie na bieżącą podróż jest jednak tworzone wyłącznie w procesie odprawy wraz z tym (((zezwoleniem na płatność elektroniczną wykorzystywanym następnie jako AFB.

Jeśli autoryzacja jest biletem elektronicznym (EFS), zawiera dalsze informacje taryfowe (produkt, ważność geograficzna itp.). Bilet elektroniczny może być anonimowy lub spersonalizowany. Anonimowy oznacza, że posiadanie EFS jest wystarczające i każdy może z niego korzystać. Spersonalizowana oznacza, że z EFS może korzystać wyłącznie określona osoba. W przypadku spersonalizowanego EFS podczas kontroli wykorzystywane są dodatkowe środki identyfikacji.

Jeśli jest to autoryzacja (((e-płatności, typ określa, czy jest ona oparta na koncie (z opcją prepaid lub postpaid), czy jest używana w połączeniu z jednostkami wartości na nośniku użytkownika. W przypadku autoryzacji (((e-płatności rozróżnia się autoryzację anonimową i nieanonimową. Anonimowe autoryzacje (((ePayment są możliwe tylko w wariancie jednostek wartości na nośniku użytkownika bez funkcji automatycznego ładowania (która wymaga konta).

Autoryzacje oparte na koncie (((ePayment authorisations are never anonymous, as the customer identity is known in the background system.

Zlecający partner umowy klienta (bKVP) inicjuje działanie (w celu późniejszej interakcji z medium użytkownika) dla swojego klienta, wysyłając zlecenie działania do usługi listy działań właściciela produktu.

W sektorze transportu umowa przewozu jest umową przewozu pasażerów (oraz bagażu, jeśli dotyczy). W transporcie publicznym prawie zawsze stosowana jest umowa przewozu osób. Sposób, w jaki, tj. za pomocą jakich środków płatniczych, roszczenie o świadczenie usługi transportowej jest rozliczane z klientem.

Urząd certyfikacji (CA) to organizacja, która wydaje certyfikaty cyfrowe. Certyfikat cyfrowy służy do przypisania określonego klucza publicznego do osoby lub organizacji (posiadacza certyfikatu). Przypisanie to jest uwierzytelniane przez urząd certyfikacji poprzez dostarczenie własnego podpisu cyfrowego.

Urząd certyfikacji jest odpowiedzialny za dostarczanie, przypisywanie i zapewnianie integralności wydawanych przez siebie certyfikatów. CA działa zatem jako zaufana strona trzecia w stosunku do posiadacza certyfikatu i strony polegającej na autentyczności certyfikatu. Urząd certyfikacji stanowi rdzeń infrastruktury klucza publicznego.

Odprawa po kontynuacji podróży to wykonanie nowej odprawy po już zakończonej odprawie w wyniku zmiany. Terminal określa odprawę po kontynuacji podróży zgodnie ze specyfikacjami właściciela produktu, którego kalkulacja taryfy opiera się na łańcuchu podróży, np. poprzez rozpoznanie lokalizacji odprawy = (poprzedniej) lokalizacji wymeldowania + kryterium czasu, w którym akceptowana jest zmiana).

Zobacz także system IN-OUT.

Mechanizmy regulujące wysyłanie i odbieranie danych między terminalem a kartą inteligentną w świecie kart inteligentnych. Opisują one szczegółowo używane warstwy protokołu OSI, wymianę danych w dobrych przypadkach, mechanizmy wykrywania błędów i mechanizmy reakcji w przypadku wystąpienia błędów.

Rozliczenie (należności) stwarza warunki do realizacji wynagrodzenia za usługi między uczestniczącymi instancjami. Rozliczenie może zestawić dane rozliczeniowe dla indywidualnego użytkownika na podstawie dostarczonych skompresowanych danych usługi, co ostatecznie umożliwia rozliczenie roszczeń.

1. gromadzenie i sortowanie danych.

2. przekazywanie danych (sieć)

3. weryfikacja danych (wyjaśnienie)

(patrz PT Service Operator)

Produkty EFM są definiowane przez właściciela produktu i każdy z nich może reprezentować jeden lub więcej produktów taryfowych do wykorzystania w elektronicznym zarządzaniu taryfami. Muszą one mieć unikalny numer dla tego właściciela produktu i być unikalne w całym systemie EFM wraz z identyfikatorem organizacyjnym właściciela produktu.

Produkt EFM jest zdefiniowany w kategoriach jego

- zasady użytkowania

- Wycena

Jako szablon produktu, produkt EFM definiuje również sposób przechowywania parametrów produktu na nośniku użytkownika w postaci określonych elementów danych. Określa również, w jaki sposób

- parametry te muszą być wykorzystane do obliczenia ceny

- automatyczna kontrola jest przeprowadzana przy użyciu danych zawartych w autoryzacji

- dane muszą być wykorzystywane do sprawdzania i automatycznego obliczania ceny w systemach IN-OUT

Bilet elektroniczny opisuje pełnoprawny bilet przechowywany na nośniku klienta, który (po niezbędnej walidacji) może być używany w tej formie przez pasażera bezpośrednio do podróży transportem publicznym, przy czym ważność przestrzenna i czasowa jest ustalona na początku użytkowania i nie może być później zmieniona.

Proces elementarny odnosi się do technicznie spójnego zestawu transakcji, działań, komunikatów i kontroli, które mogą być dystrybuowane w różnych systemach i przypisywane do poszczególnych przypadków użycia. Proces elementarny zawiera zatem zazwyczaj kilka przypadków użycia.

Aplikacje i autoryzacje można odblokować, a następnie ponownie wykorzystać w ramach (((eTicket Germany. Odblokowanie następuje, gdy status aplikacji lub autoryzacji na nośniku użytkownika zmieni się z powrotem na "aktywny". Dzięki temu aplikacja lub autoryzacja może być ponownie używana.

Odblokowanie jest możliwe tylko na autoryzowanych terminalach partnera umowy klienta.

Jeśli flaga blokująca zostanie ponownie usunięta za pomocą odblokowania w aplikacji, dowód odblokowania zostanie wysłany do systemu zaplecza partnera umowy z klientem. Jeśli flaga blokująca zostanie ponownie usunięta za pomocą odblokowania w autoryzacji, certyfikat odblokowania zostanie wysłany do systemu zaplecza partnera umowy z klientem, a także do właściciela produktu.

Skasowanie w kontekście transportu publicznego oznacza wykorzystanie biletu, który był przeznaczony do jednorazowego użytku w dowolnym momencie odpowiadającym produktowi taryfowemu biletu. Wykorzystanie biletu jest poświadczane pieczątką (bilet papierowy) lub elektronicznym dowodem w bilecie elektronicznym, co z kolei anuluje bilet, ponieważ nie można go użyć ponownie. Z drugiej strony, dzięki temu procesowi bilet staje się ważny tylko na bieżącą podróż.

Rejestrowanie oznacza rejestrowanie procesów wejścia-wyjścia (np. zameldowania i wymeldowania) w systemach IN-OUT oraz ich gromadzenie i przekazywanie właścicielowi produktu. Dowód tego jest przechowywany na nośniku użytkownika. W tym kontekście odnosi się to zawsze do technicznego rejestrowania danych w celu obliczania usług, a nie na przykład do statystycznego rejestrowania liczby pasażerów itp. Dostawca usług transportu publicznego jest odpowiedzialny za rejestrowanie danych. Wynika to z faktu, że musi on być w stanie przedstawić dowody świadczonych przez siebie usług i przeprowadzić rejestrację w tym celu. Dostawca usług transportu publicznego spełnia zatem część roli gromadzenia i przekazywania danych zgodnie z normą ISO 24014 i jest odpowiedzialny za rejestrowanie usług i danych o przychodach z korzystania z zezwoleń podczas korzystania z usług transportowych przedsiębiorstw transportu publicznego.

Uwaga: Procesy kontroli mogą być również rozumiane jako gromadzenie, ale stanowią odrębny przypadek użycia, patrz Kontrola.

Dane generowane przez terminale rejestrujące i przesyłane do systemu działającego w tle.

Termin zbiorczy dla wszystkich typów urządzeń peryferyjnych służących do rejestrowania korzystania z usług transportowych w pojazdach i na przystankach w systemach IN-OUT. Należą one do grupy terminali akceptujących.

Podwyższona opłata transportowa (EBE) jest należna, jeśli klient nie może okazać ważnego biletu.

s. Autoryzacja / Uprawnienie

Czas (automatycznego) określania wartości usługi transportu publicznego w oparciu o taryfę (określanie ceny) i naliczanie wartości zgodnie z zapisaną metodą płatności (czas płatności). Procesy ustalania ceny i płatności są rozdzielone, nawet jeśli płatność jest dokonywana natychmiast po jej ustaleniu, szczególnie w przypadku ustalania ceny z góry. W zależności od taryfy możliwe są tylko niektóre metody płatności.

Dostępne są następujące warianty obliczania taryfy:

- z ceną z góry: Taryfa jest ustalana przed podróżą lub przejazdem. Zazwyczaj oznacza to, że bilet jest kupowany przed rozpoczęciem podróży. Ważne metody płatności to:

o obciążenie konta (((autoryzacja e-płatności

o natychmiastowa płatność gotówką,

o obciążenie karty kredytowej, debetowej, gotówkowej itp.

- trip-priced: Opłata za przejazd jest ustalana bezpośrednio po zakończeniu podróży (zazwyczaj w momencie wymeldowania). Prawidłowe metody płatności w ramach głównej aplikacji to

o Obciążenie na podstawie autoryzacji jednostki wartości (WEB)

- post-priced: Opłata za przejazd jest ustalana w określonym czasie po zakończeniu podróży, zwykle w systemie działającym w tle. Oznacza to, że płatność za usługę transportu publicznego jest dokonywana dopiero po pewnym czasie od skorzystania z usługi. Tylko procedura post-priced umożliwia klientowi uzyskanie najlepszej ceny. Ważne

metody płatności to

o Obciążenie rachunku

o Konto post-paid lub konto przedpłacone partnera umowy klienta

Uwaga: Czas płatności nie ma nic wspólnego z metodą płatności klienta przy użyciu jego autoryzacji (((e-płatności (terminy prepaid i postpaid są tam również używane)). Jak widać w przypadku procedury po wycenie, późniejsza płatność może być dokonana za pośrednictwem konta przedpłaconego i odpowiedniej autoryzacji przedpłaty (((e-płatności).

Podróż to korzystanie ze środka transportu od momentu wejścia na pokład do opuszczenia go.

Odcinek podróży to część podróży. Można go scharakteryzować poprzez wskazanie dwóch przystanków.

Licznik nieprawidłowego użycia jest zwiększany po wprowadzeniu nieprawidłowego kodu PIN. Z reguły kod PIN może zostać wprowadzony nieprawidłowo trzy razy, po czym obiekt chroniony kodem PIN (w tym przypadku zwykle karta chipowa) zostaje zablokowany i musi zostać ponownie odblokowany przy użyciu kodu PUK. Jeśli kod PIN zostanie wprowadzony poprawnie, licznik nieprawidłowych operacji zostanie zresetowany do 0.

Zewnętrzny partner umowy z klientem przeprowadza transakcje za pomocą aplikacji lub autoryzacji pierwotnych partnerów umowy z klientem, do których jest upoważniony na mocy warunków użytkowania. Dotyczy to przede wszystkim korzystania z (((upoważnień do płatności elektronicznych wydanych przez głównego partnera umowy z klientem i przeznaczonych do wykorzystania przez zewnętrznego partnera umowy z klientem w celu korzystania z usług transportu publicznego (np. zakup biletu w środowisku zewnętrznego partnera umowy z klientem za pomocą (((upoważnienia do płatności elektronicznych głównego partnera umowy z klientem.

Zobacz także model roli w Spec-Main (dla KA 1.X Spec HD BOM).

Wspólne centrum usług (GSS) jest działającym w tle systemem abonenckim, który przejmuje i przetwarza zadania specyficzne dla roli podłączonych abonentów w centralnej lokalizacji. Ponadto wstępnie przetworzone komunikaty są przekazywane do systemów abonenckich KA za pośrednictwem sieci interoperacyjności (funkcja przełączania).

Wszystkie systemy komputerowe elektronicznego systemu zarządzania opłatami, które przetwarzają i zarządzają danymi od hierarchii terminala akceptacji.

Inicjalizacja aplikacji PT tworzy strukturę danych zdefiniowaną dla aplikacji na chipie i wypełnia pola danych predefiniowanymi wartościami. Status aplikacji otrzymuje wartość początkową "initialised". W tym stanie aplikacja nie może być jeszcze używana. Musi ona również zostać aktywowana. Zobacz Aktywacja aplikacji.

Rodzaj terminala akceptacji w systemie zarządzania opłatami operatora systemu, w którym (częściowy) dowód usługi jest automatycznie tworzony w aplikacji na początku podróży i automatycznie uzupełniany lub uzupełniany w trakcie podróży (zwykle na jej końcu). Przedstawicielami systemów są

- Systemy check-in/check-out (CICO),

- Systemy Be-in/Be-out (BIBO).

- Systemy check-in/be-out (CIBO)

(Częściowy) zapis wyników utworzony automatycznie na początku podróży jest uznawany za dowód posiadania ważnych uprawnień do prowadzenia pojazdu. W systemach BIBO dowód wykonania usługi jest uzupełniany poprzez zapisanie na nośniku użytkownika następnego przystanku po odjeździe środka transportu.

Interoperacyjność jest cechą charakterystyczną produktu lub systemu, którego interfejsy są w pełni znane, dzięki czemu może on współpracować z innymi obecnymi lub przyszłymi produktami lub systemami bez żadnych ograniczeń, zarówno w zakresie implementacji, jak i dostępu.

Poniższy opis odnosi się do definicji interoperacyjności w ramach (((eTicket Deutschland:

Gwarancja zarówno ciągłej podróży, jak i selektywnych indywidualnych podróży dla pasażera przy użyciu tego samego nośnika użytkownika z tą samą aplikacją w sieciach (systemach zarządzania taryfami) wszystkich zintegrowanych umownie przedsiębiorstw transportowych. Więcej informacji na temat interoperacyjności można znaleźć tutaj.

W systemach interoperacyjnych duża ilość danych musi być wymieniana między różnymi partnerami systemowymi w różnych indywidualnych systemach. Zadanie to wykonuje sieć interoperacyjności. Uwalnia ona jednostki operacyjne (wydawcę aplikacji, usługę listy kontroli i odwołań, właściciela produktu, partnera umowy z klientem i dostawcę usług) od konieczności bycia informowanym o szczegółach transferu danych.

Sama sieć interoperacyjności (ION) odnosi się do całej sieci, która jest logicznie i fizycznie wymagana do wysyłania wiadomości między systemami abonenckimi w całych Niemczech.

Posiadacz karty to osoba, która ma faktyczne uprawnienia do dysponowania kartą. Jeśli karta jest używana, posiadacz karty staje się jej użytkownikiem. Posiadacz karty jest właścicielem karty. Niekoniecznie jest on posiadaczem karty.

Termin typ karty jest używany w KA w celu rozróżnienia między różnymi technicznymi wersjami karty chipowej (np. karta kredytowa, karta z emulacją Mifare itp.).

Nazwa Kernapplikation (KA) oznacza ogólnoniemiecki standard dla elektronicznych systemów zarządzania opłatami dla różnych operatorów transportu publicznego lub systemów w wersjach 1 i 2. Nowa nazwa (((etiCORE odnosi się do wersji 3. Oba standardy obejmują bezpieczeństwo, certyfikację, koncepcję organizacyjną i odpowiednie interfejsy systemowe w e-biletach, co umożliwia interoperacyjne korzystanie z aplikacji transportu publicznego na nośniku użytkownika.

Określają one

- realizację specyfikacji na chipie w nośniku użytkownika i jego interfejs do niezbędnych terminali akceptacji

- opis niezbędnych interfejsów między terminalami akceptacyjnymi a systemami działającymi w tle

- opis niezbędnych interfejsów między systemami zaplecza różnych systemów zarządzania opłatami i odpowiednimi instancjami

- dowód zgodności ze standardem i bezpieczeństwa poprzez procedurę certyfikacji

Zarządzanie kluczami dotyczy całej obsługi kluczy kryptograficznych, tj. generowania, dystrybucji, administrowania, przechowywania, wymiany i monitorowania kluczy kryptograficznych (patrz także klucz symetryczny/kryptografia asymetryczna).

W Niemczech zadania te są zapewniane przez Scheme Managera (który obejmuje tylko jeden aspekt) i są wykonywane przez centralną instancję, podrzędną rolę Security Managera. W (((etiCORE pominięto zarządzanie kluczami symetrycznymi w systemach partnerskich właściciela produktu i partnera umowy z klientem.

Kontrola weryfikuje, czy klient/użytkownik spełnia wszystkie wymagania niezbędne do korzystania z usług transportu publicznego:

- czytelny nośnik klienta,

- ważny wniosek (w tym sprawdzenie listy blokowania wniosków)

- ważne zezwolenie (w tym sprawdzenie listy blokowania zezwoleń)

- ważny produkt (ważność taryfy)

Jest to przede wszystkim w interesie dostawcy usług transportu publicznego, który fakturuje swoje usługi na podstawie dowodu wykonania. Jeśli jeden z tych warunków nie jest spełniony, kontrola inicjuje naliczenie podwyższonej opłaty transportowej. Kontrola inicjuje również zablokowanie aplikacji lub autoryzacji na nośniku klienta, jeśli odpowiednie wpisy blokujące zostaną znalezione na liście blokujących. Od 2GSI / (((etiCORE blokowanie na nośniku użytkownika może być przeprowadzane bez SAM.

W 1GSI / KA 1.X dowód kontroli jest zapisywany na nośniku użytkownika oprócz wysyłania go do właściciela produktu; od 2GSI / (((etiCORE dowód kontroli jest wysyłany tylko do właściciela produktu. Oznacza to, że w przypadku 2GSI / (((etiCORE kontrola jest możliwa bez SAM. Pod względem ISO 24014 kontrola może być rozumiana jako część rejestracji, ale jest niezależnym przypadkiem użycia.

Usługa list kontrolnych i odwołań (KOSE) udostępnia listy z wpisami odwołań dla

- zezwoleń

- Aplikacje

- Bezpieczne moduły aplikacji (SAM)

- klucze

- organizacji

Wpisy na dedykowanych listach wskazują, że dana instancja jest skradziona, naruszona, nieważna itp. W przypadku wszystkich tych instancji można wykonać nowe polecenia w celu dodania wpisu do tych hotlist lub usunięcia wpisu z tych hotlist:

- przez Menedżera Schematu w odniesieniu do organizacji, SAM i kluczy (w (((etiCORE tylko klucze uwierzytelniające))

- przez partnerów kontraktowych klienta w odniesieniu do wniosków i autoryzacji.

Ponadto, w ramach zbierania i przekazywania (patrz ISO 24014-1), poświadczenia odwołania (odnoszące się do autoryzacji lub aplikacji) są przetwarzane przez zbieranie przez dostawców usług i udostępniane właścicielom produktów (autoryzacje) i wystawcom aplikacji (aplikacje). Zobacz model roli w Spec Main.

Nośnik aplikacji. Zobacz także nośnik użytkownika.

Dane klienta to ogólny termin określający preferencje i profil klienta.

Indywidualne, możliwe do wybrania dane klienta, które są przechowywane w aplikacji na nośniku klienta i mogą być wykorzystane na przykład do przyspieszenia odprawy. Nie są one automatycznie związane z umową. Są to preferowane cechy biletu.

Wszystkie główne dane osobowe opisujące klienta, które są przechowywane w aplikacji na nośniku klienta. Ze względu na określoną strukturę danych, profil klienta może być interpretowany w ten sam sposób dla wszystkich interakcji z aplikacją. Może on być jednak wykorzystywany w zależności od operatora.

Obsługa klienta jest zdefiniowana w normie ISO 24014-1 i obejmuje kompleksowe zarządzanie informacjami i reklamacjami dla każdego klienta w związku z podstawową aplikacją VDV, w tym skradzionymi lub uszkodzonymi nośnikami użytkownika. Obejmuje to funkcje call center, usługi internetowe i może odbywać się za pośrednictwem regionalnych punktów obsługi.

Umowa z klientem w rozumieniu (((eTicket Germany reprezentuje relację między firmą transportową świadczącą klientowi usługę a klientem. Umowa z klientem opisuje warunki, na jakich klient może korzystać z usług oferowanych przez przewoźnika. Jednocześnie klient otrzymuje prawo do korzystania z usługi. Umowa z klientem reguluje naliczanie opłat i rozliczenia między partnerem umowy z klientem a klientem. Umowa z klientem określa przede wszystkim parametry taryfy użytkownika, które mają być stosowane.

Umowa z klientem jest zawsze opatrzona identyfikatorem organizacji partnera umowy z klientem. Umowa z klientem jest przechowywana w formie elektronicznej jako autoryzacja (jako (((autoryzacja e-płatności lub bilet elektroniczny) na podstawie produktu EFM zdefiniowanego przez właściciela produktu w aplikacji transportu publicznego.

Rola partnera umowy z klientem jest specjalną rolą w głównej aplikacji. Składa się z kilku ról zdefiniowanych w normie ISO 24014-1:

- Product Retailer

- Sprzedawca aplikacji

- Obsługa klienta

- Dostawca tożsamości

- Dostawca konta

- Dostawca płatności

Partner umowy z klientem reguluje procesy sprzedaży klienta, biorąc pod uwagę zależności umowne z kierownikiem programu i kierownikiem produktu różnych usług mobilnych. W szczególności, partner umowy z klientem jest odpowiedzialny za księgowanie, biletowanie i fakturowanie różnych usług mobilności dla klienta.

W związku z tym przyjmuje on rolę sprzedawcy produktów, sprzedawcy aplikacji (wystawcy instancji) i dostawcy kont. Jako dostawca konta korzysta z usług wybranych przez siebie dostawców płatności, z którymi ma stosunki umowne. Partner umowy z klientem może działać w roli głównego partnera umowy z klientem lub w roli zewnętrznego partnera umowy z klientem. Zobacz model roli w Spec Main.

Jednostka personalizacji partnera umowy klienta obejmuje komunikację między nośnikiem użytkownika a SAM. Składa się ona zatem z co najmniej jednego urządzenia do odczytu/zapisu z SAM.

Jeśli nośnik użytkownika ma zostać wydrukowany w formie karty chipowej, odpowiednia drukarka jest również częścią CIP-PE. Na przykład, maszyna do drukowania listów w masowej personalizacji jest ostatecznie również CIP PE.

Jednostka sprzedaży partnera kontraktowego klienta (KVP-VE) dostarcza oprogramowanie do wyboru aplikacji do personalizacji, autoryzacji i komunikacji z referencyjnym systemem tła oraz zapewnia niezbędne komponenty wejściowe i wyjściowe (monitor/klawiatura).

Dowód usługi reprezentuje dane usługi przechowywane na nośniku użytkownika do celów kontrolnych, które opisują wykorzystanie usługi klienta w systemie IN-OUT.

Pierwszy poziom bezpieczeństwa w architekturze bezpieczeństwa podstawowej aplikacji VDV (w (((eTicket Germany)). Na poziomie 1 używana jest bardzo ograniczona liczba identyfikatorów organizacji, które są używane jako przykłady dla wszystkich uczestników w ich rolach do certyfikacji komponentów systemu. Te specjalne identyfikatory organizacji są zaprojektowane w taki sposób, że nie są rozpoznawane przez żaden skuteczny system. W przypadku pierwszych testów podczas opracowywania komponentów systemu zaleca się pracę na poziomie 1.

Drugi poziom bezpieczeństwa w architekturze bezpieczeństwa głównej aplikacji VDV (w (((eTicket Germany)). Na poziomie 2 wszystkie komponenty bezpieczeństwa KA (klucze symetryczne / asymetryczne, SAM i nośnik użytkownika) są generowane i używane z identyfikatorami organizacji, które są przypisane jako uzupełnienie aktywnych lub identyfikatorów organizacji poziomu 3 przypisanych do uczestników.

W wersji KA 1.X pierwszy bit w 2-bajtowym identyfikatorze organizacji jest w tym celu zastępowany. W rezultacie do identyfikatora organizacji poziomu 3 dodawana jest wartość 8000 w systemie szesnastkowym lub 32768 w systemie dziesiętnym. Na przykład organizacja 5600 szesnastkowo lub 15E0 szesnastkowo staje się identyfikatorem organizacji 95E0 szesnastkowo lub 38368 dziesiętnie na poziomie 2.

W (((etiCORE poziom nie jest już kontrolowany przez sam identyfikator organizacji (który nie jest ustawiony na 2 bajty), ale przez używany certyfikat. Oznacza to, że identyfikatory organizacji na poziomie 2 i poziomie 3 są takie same, a tylko zarządzanie bezpieczeństwem lub dane wyjściowe certyfikatów kontrolują, w jaki sposób można korzystać z bieżącego środowiska systemowego.

Trzeci (najwyższy) poziom bezpieczeństwa w architekturze bezpieczeństwa podstawowej aplikacji VDV w (((eTicket Deutschland. Na poziomie 3 wszystkie komponenty bezpieczeństwa KA (klucze symetryczne / asymetryczne, SAM i nośnik użytkownika) są generowane i używane z identyfikatorami organizacji poziomu 3, których uczestnicy używają w swoich systemach KA do unikalnej identyfikacji, uwierzytelniania, szyfrowania i bezpieczeństwa transakcji.

Wszystkie elementy bezpieczeństwa służące do kompleksowej ochrony interesów uczestników są tutaj chronione i nie mogą być dostępne dla osób trzecich. Poziom 3 jest zarezerwowany dla aktywnego działania. W aktywnym działaniu (((eTicket Deutschland używane i rozpoznawane są tylko obiekty wartości (np. (((autoryzacje ePayment), które zostały utworzone z identyfikatorami organizacji poziomu 3. W przypadku standardów (((etiCORE można używać wyłącznie certyfikatów poziomu 3.

Dowód autentycznie rejestruje transakcję na poziomie nośnika użytkownika. Może to być wydanie autoryzacji, zameldowanie lub wymeldowanie, dowód kontroli, zablokowanie, odblokowanie, anulowanie, pobranie jednostek wartości itp.

Wersje awaryjne są używane w celu ograniczenia awarii i szkód (finansowych) w przypadku naruszenia bezpieczeństwa klucza. W efekcie oznacza to, że klucze awaryjne są przechowywane w aplikacji oprócz odpowiednich kluczy, gdy aplikacja jest spersonalizowana. Możliwe jest przełączenie na te klucze awaryjne podczas pracy.

Począwszy od (((etiCORE, termin ten nie jest już używany, ponieważ inny mechanizm jest używany do użycia innego klucza po naruszeniu bezpieczeństwa klucza. Zobacz Klucz symetryczny.

Użytkownik jest w posiadaniu nośnika użytkownika i jest podróżnym (pasażerem) w rozumieniu normy ISO 24014-1. Korzysta on z usługi transportu publicznego w ramach określonego produktu taryfowego. W przeciwieństwie do klienta, użytkownik może również uczestniczyć anonimowo w (((eTicket Germany.

s. Kundenmedium / Customer Medium.

Parametry taryfy użytkownika mogą być zmieniane przez użytkownika aplikacji w terminalach w porównaniu z ważną umową przewozu na podróż, do której mają zastosowanie zmienione parametry (np. regulacja dotycząca przewozu na wynos lub zmiana klasy usługi).

Liczniki użytkowania są wykorzystywane do przyznawania klientom specjalnych taryf w oparciu o usługi transportowe, z których korzystają w przypadku automatycznego obliczania taryf. W przypadku obliczania taryfy po cenie, scenariusz najlepszej ceny lub premii może być również realizowany bez liczników użytkowania.

W przypadku obliczania taryfy według ceny przejazdu w połączeniu z wykorzystaniem autoryzacji jednostki wartości, licznik wykorzystania jest jednak wymagany w celu przyznania specjalnych taryf za wykorzystane usługi transportowe (np. obliczenie biletu dziennego na podstawie czwartej pojedynczej podróży).

s. Kryptografia asymetryczna / Kryptografia asymetryczna

Dostawca usług transportu publicznego oferuje usługi transportowe klientowi, który uzyskał odpowiednie zezwolenie na korzystanie z tych usług. Umowa transportowa jest zawierana między dostawcą usług transportu publicznego a użytkownikiem/pasażerem w momencie wejścia na pokład środka transportu.

Usługodawca nabywa prawo do uczestnictwa w systemie EFM od zarządzającego systemem, regulowane stosunkiem umownym (((umowa o uczestnictwo w systemie eTicket). Dostawca usług transportu publicznego zawiera umowy z menedżerami produktów w celu akceptacji produktów i zapłaty za świadczone usługi transportowe, a także z partnerami kontraktowymi klienta w celu rozliczenia powstałych należności (poprzez rozliczenie należności).

Zobacz także model roli w Spec-Main (dla KA 1.X Spec HD BOM).

Wyznaczone jednostki wartości opłacane przez klienta, które są wykorzystywane do bezgotówkowego korzystania z usług transportowych. Jednostki wartości w transporcie publicznym są nabywane za ważne i akceptowane środki płatnicze w autoryzowanych punktach transportu publicznego, przechowywane w aplikacji transportu publicznego i sukcesywnie pobierane z pamięci w autoryzowanych terminalach transportu publicznego zgodnie z wykorzystywanymi usługami (transportowymi). Jednostki wartości w transporcie publicznym odpowiadają limitowi wielu przejazdów w transporcie publicznym.

Identyfikator organizacji jednoznacznie identyfikuje organizację w całym zakresie głównej aplikacji. Identyfikator organizacji składa się z numeru organizacji, który jest przypisywany przez Menedżera Systemu (VDV ETS) podczas rejestracji za pośrednictwem narzędzia ASM w momencie zawierania umowy (((eTicket). Organizacje, którym przypisano identyfikator, są podmiotami prawnymi, zazwyczaj firmami transportowymi i stowarzyszeniami. W wyjątkowych przypadkach mogą to być również wyraźnie wyodrębnione jednostki operacyjne dużej firmy.

Osobisty numer identyfikacyjny (PIN) to numeryczny (lub rzadziej: alfanumeryczny) kod dostępu używany do uwierzytelniania użytkownika uzyskującego dostęp do systemu.

W szczególności używany jako część głównej aplikacji: Czterocyfrowy tajny kod, który może być użyty do odczytu danych klienta na nośniku użytkownika. Te dane klienta mogą być odczytywane wyłącznie w sposób uwierzytelniony przez autoryzowane terminale lub przez samego klienta przy użyciu kodu PIN.

Personalizacja w rozumieniu (((eTicket Germany oznacza dodanie danych osobowych do aplikacji nośnika użytkownika. Tworzy to profil klienta i, w stosownych przypadkach, preferencje klienta. Procesy techniczne w tym zakresie są opisane w specyfikacji nośnika użytkownika.

Termin "osobisty" jest zwykle używany w związku z zezwoleniami i oznacza, że zezwolenie jest ważne tylko dla określonej osoby i nie może być przenoszone.

Infrastruktura klucza publicznego (PKI) odnosi się do systemu, który może wydawać, dystrybuować i weryfikować certyfikaty cyfrowe. Certyfikaty wydawane w ramach PKI służą do zabezpieczania komunikacji komputerowej. PKI jest wykorzystywana w dziedzinie kryptografii asymetrycznej.

Odnosi się do konta, za pośrednictwem którego usługi transportu publicznego, z których korzysta klient, są obciążane za pośrednictwem przedpłaconej autoryzacji płatności (PEB). W przypadku opcji autoload uzgodniona kwota pieniędzy może zostać doładowana na konto klienta w instytucji kredytowej znanej partnerowi umowy z klientem po osiągnięciu uzgodnionej w umowie wartości progowej. Usługi transportu publicznego, z których korzysta się za pośrednictwem autoryzacji, są gromadzone niezależnie od danych osobowych klienta i obciążane niezwłocznie za pośrednictwem tego konta. Dla każdego konta przedpłaconego istnieje co najmniej jedna umowa z klientem.

Uwaga: Skonfigurowanie anonimowej metody płatności przedpłaconej (bez automatycznego ładowania) byłoby zasadniczo możliwe, ale nie jest obecnie planowane jako część głównej aplikacji.

Główny partner umowy z klientem wydaje wniosek lub upoważnienie. Jego identyfikator organizacji jest wprowadzany do wniosku lub upoważnienia, aby umożliwić przypisanie wniosku lub upoważnienia do głównego partnera umowy z klientem, który je wydał.

Odnosi się do konta, za pośrednictwem którego usługi transportu publicznego, z których korzysta klient, są rozliczane za pośrednictwem autoryzacji płatności elektronicznych (POB) na podstawie faktury lub za pośrednictwem konta klienta instytucji kredytowej znanej głównemu partnerowi umowy z klientem. Usługi transportu publicznego, z których klient korzysta za pośrednictwem autoryzacji, są gromadzone niezależnie od danych osobowych klienta i rozliczane za pośrednictwem tego konta w terminie uzgodnionym w umowie. Dla każdego konta abonamentowego istnieje co najmniej jedna umowa z klientem.

Nie jest możliwe ustanowienie procedury płatności post-paid anonimowo.

Termin produkt jest używany w głównym zastosowaniu w znaczeniu produktu taryfowego transportu publicznego lub produktu EFM.

Product Clearing (PCL) to scentralizowany system, który tworzy ogólnoniemiecki serwer taryf oraz zna i może obliczać wszystkie taryfy podłączonych uczestników za pośrednictwem modułów taryfowych zgodnie z PKM. Product Clearing określa prawidłowe taryfy i ceny dla łańcucha podróży klienta.

PCL wykorzystuje moduły taryfowe PKM do obliczania taryf. Ten otwarty standard cyfrowego mapowania danych taryfowych jest częścią podstawowej aplikacji VDV i nie tylko dostarcza informacji na temat zapytań związanych z produktem, ale także oblicza prawidłowy produkt taryfowy dla podróży w oparciu o określone parametry taryfy użytkownika.

Wszyscy menedżerowie produktów zaangażowani w (((eTicket Deutschland udostępniają swój aktualny moduł taryfowy w systemie. Tworzy to centralny punkt dla wszystkich danych taryfowych w Niemczech.

Właściciel produktu opracowuje produkty EFM na podstawie swoich taryf za usługi transportowe w jednym lub kilku obszarach geograficznych, w których różni dostawcy usług transportu publicznego oferują usługi transportowe. Umowa uczestnictwa reguluje niezbędne warunki między właścicielem produktu, partnerami umowy z klientami i dostawcami usług transportu publicznego. Właściciel produktu nabywa prawo, regulowane stosunkiem umownym, do uczestnictwa w systemach EFM od zarządzającego systemem i do zarejestrowania tam swoich produktów. Otrzymuje on niezbędne identyfikatory i informacje od menedżera systemu w celu zarządzania swoimi tokenami, uprawnieniami i modułami bezpieczeństwa.

W ramach zarządzania bezpieczeństwem właściciel produktu upoważnia partnerów kontraktowych klienta do wydawania autoryzacji. Właściciel produktu upoważnia partnerów kontraktowych klienta do sprzedaży swoich produktów.

Zobacz także model roli w Spec Main (dla KA 1.X Spec HD BOM)

Autoryzacja referencyjna zapewnia zdefiniowaną strukturę, która może być używana zarówno jako zautomatyzowana autoryzacja podróży, jak i bilet elektroniczny. Z jednej strony stanowi ona zalecaną specyfikację zautomatyzowanej autoryzacji podróży ze ściśle określonymi strukturami specyficznymi dla produktu do użytku interoperacyjnego.

Z drugiej strony, autoryzacja referencyjna dla biletu elektronicznego jest propozycją ze ściśle zdefiniowanymi strukturami specyficznymi dla produktu, które mogą być wykorzystywane przez menedżerów produktu przy wdrażaniu biletów elektronicznych. Alternatywnie, TLV-EFS oferuje tutaj nieco bardziej elastyczne i zoptymalizowane pod kątem pamięci rozwiązanie domyślne

System referencyjny jest wyimaginowanym systemem, a terminal referencyjny wyimaginowanym terminalem, który łączy zdefiniowane podstawowe funkcje. Te podstawowe funkcje można znaleźć w rzeczywistym użyciu w różnych systemach lub typach terminali powiązanych z systemem. Funkcjonalności realizowane w rzeczywistym systemie lub terminalu są tam wdrażane analogicznie do przypadków użycia w specyfikacjach systemu (z (((etiCORE: KVP-Ref - Dienstleisterumgesetzt.

Instancja w ramach infrastruktury klucza publicznego, do której osoby, maszyny lub podrzędne urzędy certyfikacji mogą składać wnioski o certyfikaty. RA sprawdza poprawność danych w żądanym certyfikacie i zatwierdza wniosek o certyfikat, który jest następnie podpisywany przez urząd certyfikacji (CA).

Sub-rola Registration Manager jest odpowiedzialna za generowanie, organizowanie i branie odpowiedzialności za identyfikatory wymagane w systemie do interoperacyjnego użytku, a także za zarządzanie umowami wymaganymi do organizacji i działania.

Zwykła wersja klucza (symetrycznego) może być używana tak długo, jak długo klucz nie zostanie naruszony. Począwszy od (((etiCORE, termin ten nie jest już używany, ponieważ inny mechanizm jest używany do użycia innego klucza po złamaniu klucza. Zob. klucz symetryczny. Patrz także wersja awaryjna.

Scheme Manager jest najwyższą instancją (((eTicket Deutschland. Zadanie to jest wykonywane przez VDV ETS. Scheme Manager łączy role wystawcy aplikacji, rejestracji i menedżera bezpieczeństwa z ISO 24014-1.

Tworzy regulacje i monitoruje je. Istnieje raz w systemie i identyfikuje się jednoznacznie. Więcej informacji można znaleźć w modelu ról w głównej specyfikacji.

Rejestr kluczy należy do specjalnej funkcji aplikacji na nośniku użytkownika. Jest on wymagany w związku z wydawaniem autoryzacji (w tym kontekście używa się mylącego terminu multiautoryzacji)*.

Używane klucze mogą być już chronione dla wydającego partnera umowy klienta i zamierzonego właściciela produktu podczas wydawania aplikacji. Klucze te zależą od identyfikatora instancji aplikacji, ale nie od indywidualnego identyfikatora autoryzacji. W razie potrzeby można wprowadzić dodatkowe klucze dla innych partnerów klienta lub właścicieli produktów.

Po wydaniu autoryzacji wymagane odniesienia do istniejących kluczy są następnie wprowadzane do rejestru kluczy; dopasowanie kluczy między nośnikiem użytkownika a terminalem w celu wydania autoryzacji jest znacznym przyspieszeniem. Autoryzacja wydana w aplikacji z rejestrem kluczy nie różni się technicznie od autoryzacji w aplikacji bez rejestru kluczy.

Od (((etiCORE korzystanie z rejestru kluczy w związku z wydawaniem autoryzacji w tej formie nie jest już konieczne ze względu na szybsze procesy kryptograficzne. Istnieje jednak nowy rejestr kluczy używany do uwierzytelniania w podobnej formie, w którym przechowywane są odniesienia do generacji kluczy uwierzytelniających, patrz także Klucz symetryczny.

*Termin multi-autoryzacja sugeruje, że może być zaangażowanych wiele autoryzacji, które mogą być używane dla różnych usług. Termin ten odnosi się jednak tylko do faktu, że klucze mogą być używane do kilku autoryzacji w celu zaoszczędzenia czasu na procesy kryptograficzne podczas dostępu. Sama multiautoryzacja nie różni się od zwykłej autoryzacji.

Secure Application Module (SAM) jest wykorzystywany jako moduł bezpieczeństwa dla partnerów umownych klienta lub dostawców usług i wykonuje funkcje związane z bezpieczeństwem terminali sprzedaży i/lub terminali sterujących, które komunikują się bezpośrednio z nośnikami użytkownika. Może być również używany do sprawdzania podpisów transakcji generowanych za pomocą nośnika użytkownika w systemach działających w tle.

Bezpieczne środowisko kryptograficzne (SCE) to logiczny komponent na urządzeniu mobilnym pasażera, który jest w stanie odbierać (lub generować) i używać kluczy kryptograficznych oraz wiązać je w sposób niezmienny z urządzeniem mobilnym i aplikacją biletową.

SCE musi być odporny na odczyt i kopiowanie kluczy na inne urządzenie mobilne i może wykorzystywać backend do uwierzytelniania kluczy. Z technicznego punktu widzenia może on zostać zaimplementowany na przykład jako biblioteka zintegrowana z aplikacją do sprzedaży biletów i wykorzystująca zasoby bezpieczeństwa urządzenia mobilnego, takie jak sprzętowy magazyn kluczy.

Architektura zabezpieczeń podstawowej aplikacji obejmuje 3 różne poziomy zabezpieczeń dla operacji testowych i rzeczywistych, które odnoszą się do korzystania z nośników użytkownika, SAM, kluczy symetrycznych i asymetrycznych oraz powiązanych certyfikatów. Poziomy bezpieczeństwa i powiązane środowiska produkcyjne u dostawcy usług bezpieczeństwa są całkowicie oddzielone w celu uniknięcia jakichkolwiek zagrożeń bezpieczeństwa. Zgodnie z oddzielnymi poziomami bezpieczeństwa, uczestnicząca firma otrzymuje dwa identyfikatory organizacji dla wersji KA 1.X, po jednym dla poziomu 2 i poziomu 3. W przypadku (((etiCORE odpowiednie certyfikaty są używane dla różnych poziomów bezpieczeństwa.

Żądanie blokady ma na celu spowodowanie umieszczenia obiektu na odpowiedniej liście blokad przez odpowiedzialną stronę trzecią. W zależności od obiektu zaangażowane są różne strony:

- Wniosek złożony do odpowiedzialnego partnera umowy klienta o umieszczenie autoryzacji na liście unieważnień. Może to zostać zainicjowane przez innego partnera umowy klienta, dostawcę usług transportu publicznego lub menedżera produktu.

- Wniosek złożony do odpowiedzialnego partnera umowy klienta o umieszczenie aplikacji na czarnej liście. Może to zrobić inny partner umowy z klientem, dostawca usług transportu publicznego lub wydawca aplikacji.

- Wniosek do wydawców aplikacji o umieszczenie modułu bezpiecznej aplikacji, klucza (z (((etiCORE tylko klucze uwierzytelniające) lub organizacji na odpowiedniej liście unieważnień. Może to zostać zainicjowane przez innego partnera umowy klienta, dostawcę usług transportu publicznego lub właściciela produktu.

Żądanie odwołania ma na celu spowodowanie usunięcia obiektu z odpowiedniej listy odwołań przez odpowiedzialną stronę trzecią. W zależności od obiektu zaangażowane są różne strony:

- Wniosek złożony do odpowiedzialnego partnera umowy klienta o usunięcie autoryzacji z listy odwołań. Może to zostać zainicjowane przez innego partnera umowy klienta, dostawcę usług transportu publicznego lub menedżera produktu.

- Żądanie skierowane do odpowiedzialnego partnera umowy klienta w celu usunięcia aplikacji z listy cofnięć. Może to zostać zainicjowane przez innego partnera umowy z klientem, dostawcę usług transportu publicznego lub wydawcę aplikacji.

- Wniosek do wydawcy aplikacji o usunięcie modułu bezpiecznej aplikacji, klucza (już nie z (((etiCORE)) lub organizacji z odpowiedniej listy unieważnień. Może to zostać zainicjowane przez innego partnera umowy klienta, dostawcę usług transportu publicznego lub właściciela produktu

Żądanie blokady służy do dodania obiektu do odpowiedniej listy blokad. Istnieją różne inicjatory w zależności od tego, który obiekt ma zostać dodany:

- Odpowiedzialny partner umowy klienta wydaje polecenie dodania autoryzacji lub aplikacji do listy odwołania.

- Menadżer Systemu zleca dodanie Modułu Bezpiecznej Aplikacji lub organizacji do listy odwołań.

- Posiadacz klucza (partner umowy z klientem, właściciel produktu lub kierownik schematu) zleca dodanie klucza (z (((etiCORE tylko kierownik schematu jako posiadacz klucza) do odpowiedniej listy odwołania.

Żądanie zwolnienia blokady służy do usunięcia obiektu z odpowiedniej listy blokad. Istnieją różne inicjatory w zależności od tego, który obiekt ma zostać usunięty:

- Odpowiedzialny partner umowy klienta wydaje polecenie usunięcia autoryzacji lub aplikacji z listy odwołania.

- Menadżer Systemu zleca usunięcie Modułu Bezpiecznej Aplikacji lub organizacji z listy odwołań.

- Posiadacz klucza (partner umowy z klientem, właściciel produktu lub menedżer schematu) zleca usunięcie klucza (od (((etiCORE zlecenie zwolnienia kluczy od menedżera schematu nie jest już możliwe) z odpowiedniej listy odwołania.

Powód blokady wskazuje, dlaczego blokada została/ma zostać nałożona.

Lista odwołań składa się z zestawu wpisów listy odwołań dla określonego obiektu (autoryzacji, aplikacji, SAM, klucza, organizacji). Jest ona używana (po odpowiedniej dystrybucji w systemach/terminalach) do wykrywania nieautoryzowanego użycia aplikacji lub autoryzacji, która ma zostać zablokowana w celu korzystania z usług ruchu.

Na podstawie listy blokowania i jej wpisów przeprowadzana jest fizyczna blokada (w przypadku zezwoleń i aplikacji), blokada logiczna lub odrzucenie zezwolenia lub aplikacji (ze względu na wpisy blokujące SAM, klucz lub organizację).

Wpis na liście odwołań jest tworzony poprzez dodanie obiektu, który ma zostać odwołany (aplikacja, autoryzacja, organizacja, SAM, klucz) do listy odwołań.

Certyfikat unieważnienia jest tworzony poprzez sprawdzenie aplikacji i autoryzacji w odniesieniu do odpowiednich list unieważnień, jeśli znaleziono odpowiedni wpis na liście unieważnień. Późniejsze fizyczne zablokowanie aplikacji lub autoryzacji jest udokumentowane autentycznym certyfikatem blokowania, który jest również wysyłany przez terminal do odpowiedzialnych instancji za pośrednictwem wiadomości.

Obiektami blokującymi w kontekście KA są aplikacje, autoryzacje, organizacje i klucze (symetryczne/asymetryczne). Za zarządzanie obiektami odwołania odpowiada instancja autoryzująca. Są one reprezentowane na listach odwołań przez wpis zawierający co najmniej ich identyfikator.

Aplikacje i autoryzacje mogą zostać zablokowane, a następnie nie mogą być już używane jako część głównej aplikacji. Blokowanie opiera się na zmianie statusu aplikacji lub autoryzacji na nośniku użytkownika W związku z wzajemnym uwierzytelnianiem między uczestnikami komunikacji można uzgodnić wspólny klucz (klucz startowy), który jest używany do bezpiecznej komunikacji między oboma partnerami. Kolejne klucze (klucze sesji) mogą być wyprowadzane z tego klucza poprzez dynamizację. Klucz (klucz sesji) można wyprowadzić z kluczy podstawowych poprzez derywację i dynamizację, który jest używany w kontekście szyfrowania lub obliczania MAC lub weryfikacji.

Termin autoryzacja statyczna odnosi się tutaj do biletu elektronicznego wyposażonego w podpis cyfrowy, który może być wydany jako niezmienny zapis danych na różnych, nawet prostych nośnikach. Może to być na przykład

- kod kreskowy 2D wydrukowany na papierze lub zapisany na urządzeniu mobilnym lub

- zapis danych przechowywany w niedrogim chipie pamięci lub telefonie komórkowym NFC i odczytywany przez interfejs ISO 14443.

Ten sam (tajny) klucz jest używany przez obu partnerów komunikacyjnych zarówno do szyfrowania, jak i deszyfrowania. Klucze symetryczne są używane w KA 1.X zarówno do wzajemnego uwierzytelniania komponentów (klucze pochodzą od menedżera schematu), jak i do autentycznego dowodu autoryzacji lub transakcji płatniczych (klucze pochodzą od właściciela produktu i partnera umowy klienta).

Aby móc szybko reagować na wymianę kluczy w przypadku ich naruszenia, a tym samym móc pracować z nowym kluczem, KA 1.X działa ze zwykłymi i awaryjnymi wersjami kluczy. W (((etiCORE wszystkie klucze symetryczne właścicieli produktów i partnerów kontraktowych klienta są pomijane. W użyciu pozostają tylko klucze symetryczne do wzajemnego uwierzytelniania komponentów.

Zamiast wersji regularnych i awaryjnych używany jest rejestr kluczy z różnymi generacjami kluczy. Te generacje kluczy są już na stałe dołączone do komponentów. Jeśli klucz uwierzytelniający znajduje się na liście unieważnień, terminal negocjuje z SAM i medium użytkownika, który klucz uwierzytelniający musi zostać użyty.

Taryfa w rozumieniu transportu publicznego to umowa lub element umowy zawierający listę stałych warunków świadczenia usług w ramach umowy transportowej. Warunki umowne nazywane są taryfą, jeśli są oferowane jednostronnie przez dostawcę wielu możliwym partnerom umownym (klientom) w ustandaryzowany sposób.

Produkt taryfowy stanowi znormalizowaną ofertę usług w zakresie korzystania z transportu publicznego i jest zdefiniowany przez następujące cechy:

- uprawnienie do usługi pod względem usługi, którą można wywołać (ważność czasowa i przestrzenna itp.)

- rodzaj produktu

- prawne warunki transportu (np. kryteria kwalifikowalności, takie jak wiek (dziecko/dorosły), status (np. student, emeryt/rencista) itp.)

- a także cena produktu (taryfa) dla określonego uprawnienia do świadczeń.

Produkt taryfowy można rozszerzyć, przyznając jedną lub więcej dodatkowych korzyści (Interservices, Intraservices) lub integrując usługi specjalne (np. wymiana w przypadku utraty) (patrz także umowa z klientem).

Umowa uczestnictwa w (((eTicket Germany. Umowa uczestnictwa reguluje specyficzne dla (((eTicket prawa i obowiązki uczestników (((eTicket Germany w ich różnych rolach między sobą (właściciel produktu, partner umowy z klientem i dostawca usług) oraz wobec menedżera systemu (VDV ETS).

Bilet jest formą zezwolenia na podróż powiązaną z produktem taryfowym w rozumieniu transportu publicznego (ÖPV) zgodnie z obowiązującymi przepisami taryfowymi. Każdy bilet odzwierciedla zawartą umowę przewozu. Rozróżnia się bilety, które są ważne natychmiast i bilety, które muszą zostać skasowane lub które obejmują dłuższy określony okres ważności (bilety okresowe). Bilety są przechowywane w całości na nośniku użytkownika jako bilety elektroniczne.

Szczególnym przypadkiem są systemy IN-OUT. W tym przypadku musi istnieć specjalny produkt taryfowy, na którego warunki użytkowania klient zgodził się z wyprzedzeniem. W trakcie podróży powiązane informacje upoważniające klienta do podróży są generowane na nośniku użytkownika za pomocą zameldowania i wymeldowania oraz zapisywania. Bilety są kwalifikowane jako produkt EFM przez menedżera produktu i wydawane klientowi lub użytkownikowi jako autoryzacja.

Bilet elektroniczny z elementami danych TVL zdefiniowanymi w załączniku do KA BOM-Spec w strukturze danych Static Product-Specific Part i Transaction Product-Specific Part, które mogą być używane zmiennie do opisu parametrów taryfy. W KA Release 1.x transakcja części specyficznej dla produktu nie jest używana dla TVL-EFS.

W informatyce transakcja jest sekwencją kroków programu, które są uważane za jednostkę logiczną, ponieważ pozostawiają bazę danych w spójnym stanie po bezbłędnym i kompletnym wykonaniu. Dlatego transakcja musi być albo wykonana całkowicie i bezbłędnie, albo wcale.

W kontekście KA/(((etiCORE transakcje w rozumieniu tej definicji odbywają się wyłącznie między nośnikiem użytkownika (w szczególności kartą chipową) a terminalem akceptującym.

Licznik czasu opóźnienia jest wskaźnikiem w minutach, który reprezentuje opóźnienie środka transportu i odpowiednio koryguje ograniczenie poszczególnych biletów, które podlegają limitowi czasowemu.

Licznik czasu opóźnienia jest również ważny dla systemów IN-OUT, jeśli występuje odpowiednie opóźnienie przy ponownej odprawie (odprawa po kontynuowaniu podróży) do innego środka transportu. Biorąc pod uwagę licznik opóźnień, nowa odprawa może być liczona jako kontynuacja podróży.

Zbiorcze określenie dla wszystkich typów obsługiwanych przez personel i automatycznych peryferyjnych urządzeń sprzedażowych służących do sprzedaży biletów elektronicznych oraz do ładowania kwot debetowych jako jednostek wartości na nośnik użytkownika lub na konto przedpłacone.

s. Jednostki wartości PT

Autoryzacja jednostki wartości (WEB) jest opcją lub pozwoleniem na korzystanie z jednostek wartości dla usług transportu publicznego na nośniku użytkownika transportu publicznego. Z jednej strony autoryzacja jednostki wartości stanowi zautomatyzowaną autoryzację podróży, w której zintegrowana jest pamięć jednostki wartości. Ma ona tę zaletę, że ogranicza dostęp do obiektu na nośniku użytkownika podczas automatycznego obliczania opłaty za przejazd w terminalu, a transakcja rezerwacji jednostki wartości jest połączona z transakcją rejestracji (transakcją podróży).

Z drugiej strony, stanowi ona również (((autoryzację e-płatności dla usług transportu publicznego poza jej wykorzystaniem w systemach IN-OUT. W zależności od umowy z klientem dostępne są następujące dwie opcje użytkowania:

- WE-preload

To wyrażenie definiuje procedurę bez zaakceptowanego debetu WEB. Ujemne saldo nie jest możliwe. Musi mieć zdefiniowane, dodatnie saldo minimalne przed użyciem PPP. Wstępne doładowanie WEB w transporcie publicznym musi zasadniczo zostać przeprowadzone przed skorzystaniem z usługi transportu publicznego.

- WE-postload

Termin ten określa procedurę, w której saldo WEB może spaść do wartości ujemnej (akceptowane przekroczenie salda) z powodu obciążenia WE transportu publicznego przed lub po skorzystaniu z usługi transportu publicznego. Procedura ta określa maksymalny dolny limit salda WEB, który jest odrzucany przez system po jego osiągnięciu. Dodając niedobór, WEB jest automatycznie równoważony ponownie przy następnym załadowaniu.

WEB umożliwia anonimowe uczestnictwo w transporcie publicznym, a następnie w wariancie WE-preload. Funkcja automatycznego ładowania jest możliwa dla autoryzacji jednostki wartości. Jednak w tym przypadku anonimowe uczestnictwo w transporcie publicznym nie jest możliwe, ponieważ wymagany jest do tego stosunek umowny.

s. Autoryzacja jednostki wartości / Przechowywana wartość (jednostka) Metoda płatności

Synonim użycia nośnika użytkownika w systemach IN-OUT, które obsługują operacje odczytu/zapisu w odległościach większych niż 20 cm. Zwykle w kontekście BeIn-Be-Out, np. z BlueTooth LE.

Centrum przełączania należące do sieci interoperacyjności (ION), które przekazuje wiadomości od subskrybenta ION do odbiorcy tej wiadomości na podstawie identyfikatora organizacji określonego jako odbiorca. Subskrybentem ION może być wydawca aplikacji, usługa listy kontroli i odwołań lub partner umowy klienta, usługodawca lub właściciel produktu. Mogą one być podłączone do tego centrum przełączania bezpośrednio lub za pośrednictwem adapterów.

Instancja "Certyfikacja" Menedżera Systemu jest odpowiedzialna za znormalizowaną specyfikację procedur certyfikacji wymaganych dla podstawowej aplikacji, za przeprowadzanie certyfikacji wszystkich komponentów systemu oraz za wydawanie certyfikatów dla odpowiednich komponentów systemu elektronicznego zarządzania opłatami.

Dodatkowy certyfikat związany z SAM, który jest wymagany do wydania kodu kreskowego VDV na podstawie autoryzacji statycznej. Nie jest on dostarczany wraz z zamówionym SAM, ale musi zostać dodatkowo zamówiony w Centrum Zaufania wraz z SAM.

Począwszy od (((etiCORE, SAM nie wymaga dodatkowego certyfikatu do wydawania kodów kreskowych VDV, ale używa certyfikatu swojego klucza podpisu do tej funkcji.