Le prix du billet (au prorata) perçu dans un système IN-OUT pour le trajet ou la section de trajet à l'embarquement, qui peut être perçu dans les cas où un prélèvement est effectué à l'avance à partir d'une mémoire d'unités de valeur de transport public ou est payé directement au moyen d'un porte-monnaie électronique.

Un ASP administrateur est une personne qui est enregistrée auprès du prestataire de services de sécurité (TSI) en tant que contact administratif dans le système KM et PKI pour une organisation. L'ASP administrateur est une spécialisation de l'ASP utilisateur, car il possède des droits administratifs supplémentaires, c'est-à-dire qu'il peut créer et bloquer des ASP utilisateurs.

L'activation de l'application de transport public sur le support de l'utilisateur s'effectue en général directement en relation avec la distribution du support de l'utilisateur au client. Pour ce faire, le statut de l'application est défini comme actif à l'aide d'une transaction de sortie, une validité temporelle est saisie et le compteur de changement de statut est initialisé. L'application est ainsi utilisable par le client.

Nettoyage de la base de données de la gestion des actions ; les ordres d'action déjà exécutés pour la dépense, le déblocage ou le retrait sont ainsi supprimés de la base de données des listes d'actions dans le système de listes d'actions du responsable du produit, pour lesquels une preuve de contrôle ou de blocage, mais pas la preuve attendue (la preuve de dépense ou la preuve de déblocage) est parvenue au responsable du produit (RP). Dans ce cas, le contractant client qui avait demandé cette action doit également être informé.

Une liste d'actions est une liste d'actions à exécuter sur le terminal d'acceptation lors du prochain contact avec un support d'utilisateur. Elle est mise à disposition par le système du responsable du produit, récupérée par les partenaires contractuels clients exécutants et ensuite distribuée sur leurs terminaux d'acceptation.

La gestion des actions représente une unité administrative dans les systèmes du contractant client mandataire, du contractant client exécutant et du responsable du produit. Les actions sont des éléments spécifiques à exécuter, qui doivent généralement être fournis sous la forme d'une liste d'actions et qui sont soumis à un cycle de vie (c'est pourquoi ils doivent être gérés).

Le service de listes d'actions est proposé par le système du responsable du produit. Grâce à ce service, les systèmes des contractants clients exécutants téléchargent les listes d'actions et les distribuent sur leurs terminaux. D'autre part, les contractants clients mandataires peuvent commander des actions auprès du responsable du produit, ce qui les place sur sa liste d'actions.

Ensemble de la technique de l'appareil (matériel et logiciel) qui permet l'échange de données avec un support utilisateur (ISO/CEI 14443). Il s'agit de :

• appareils pour la création de tickets complets (sur puce ou/et papier)
• appareils pour la création et/ou la complétion de tickets
• appareils pour la consultation d'informations et l'impression de tickets et de justificatifs/reçus
• Appareils pour le chargement d'unités de valeur de transport public
• Appareils mobiles pour le contrôle et/ou la validation des tickets
• Appareils pour l'activation et la personnalisation de l'application.

On distingue les types de système suivants : système avec présélection manuelle pour l'achat de tickets et système IN-OUT.

Une application se compose de données, de commandes, de processus, d'états, de mécanismes, d'algorithmes et de code de programme, par exemple au sein d'une carte à puce ou d'un smartphone, afin de les exploiter dans le cadre d'un système donné. Parmi les mécanismes, on compte l'intégration dans l'architecture de sécurité du système global concerné ainsi que les protocoles de transmission des cartes à puce.

L'éditeur de l'application (AH) détient le contrat d'application pour l'utilisation de l'application de transport public. Il autorise la revente de l'application par un partenaire contractuel client à un client. Il définit les règles d'application et accorde à un responsable de produit, à un partenaire contractuel client et à un prestataire de services le droit de participer aux systèmes EFM, leur fournit les identifiants nécessaires et leur accorde le droit d'utiliser les clés de l'éditeur d'application. Il autorise les partenaires contractuels clients à éditer des applications sur le support utilisateur. En outre, il est responsable de la mise à disposition d'informations sur l'ID d'instance de l'application (identifie un support utilisateur) en cas de demandes concernant des supports utilisateurs défectueux. L'éditeur de l'application met en œuvre une gestion du cycle de vie pour toutes les instances de l'application.

Identifiant de l'application / Application Identifier

Identification de l'application qui se trouve sur le support utilisateur. Comme il peut y avoir par exemple plusieurs applications sur une carte à puce, l'identifiant permet de sélectionner la bonne application (dans ce cas, l'application TP).

Outil ASM

L'outil ASM (Application and Security Management Tool) est le système central de service et de gestion pour le (((eTicket Allemagne). Il soutient les tâches essentielles du Scheme Manager pour la gestion des applications et de la sécurité dans le (((eTicket Allemagne comme

- Portail de service pour l'enregistrement du (((eTicket Allemagne)

- Service client pour les opérateurs de transport et les fabricants

- Gestion des clients, des fabricants et des participants au (((eTicket)

Allemagne

- Mise à disposition de documents KA

- Commande de composants de sécurité KA, traitement et vérification des commandes.

ainsi qu'une partie des processus de suivi de la sécurité.

et il représente le référentiel KA de l'éditeur de l'application (AHS).

L'outil ASM est accessible via https://asmtool.eticket-deutschland.de/asm-toolextern.

Cryptographie asymétrique / Asymmetric Cryptography

Les méthodes de cryptographie asymétrique utilisent des paires de clés composées d'une clé publique (en anglais public key) et d'une clé privée (en anglais private key). La clé publique n'est pas secrète, elle doit être connue du plus grand nombre possible d'autres utilisateurs. Elle permet d'effectuer des opérations publiques, c'est-à-dire de crypter des messages ou de vérifier des signatures numériques. Dans ce contexte, il est important qu'une clé publique puisse être attribuée sans équivoque à un utilisateur. Ceci est garanti par un certificat. Pour décrypter un texte crypté ou signer un message, la clé privée est nécessaire. Contrairement aux procédures symétriques, dans lesquelles plusieurs utilisateurs se partagent une clé symétrique, dans les procédures asymétriques, seul un utilisateur dispose de la clé privée (secrète). C'est cette circonstance qui permet d'attribuer clairement une signature à un utilisateur.

Partenaire contractuel client exécutant / Executing Customer Contract Partner

Le partenaire contractuel client exécutant (aKVP) autorise l'exécution d'une action avec un support d'utilisateur sur l'un de ses terminaux. Pour ce faire, il doit être connecté au service de listes d'actions et à la gestion des actions du responsable du produit via des listes d'actions. Il peut être en même temps partenaire contractuel client mandataire (bKVP).

Édition de l'application / Issuing the Application

Il peut y avoir plusieurs entités autorisées par l'éditeur de l'application à créer l'application sur un support utilisateur conformément à la spécification donnée et/ou à l'activer pour l'utilisation. L'édition peut également se faire par le biais de la distribution. Elle se fera toujours par l'intermédiaire d'un partenaire contractuel client. L'application sur le support utilisateur est également appelée application de transport public.

Autoload

En cas d'autorisation d'unités de valeur : Chargement automatique avec une quantité convenue d'unités de valeur de transport public pour un contrat client existant en fonction de la réalisation de critères convenus contractuellement (par ex. atteinte ou non d'un montant minimum). Cela se produit pour les unités de transport public stockées dans le support d'utilisateur à chaque terminal d'acceptation qui détecte que le montant de chargement minimum n'est pas atteint et qui prend en charge la fonction Autoload. Tous les montants de chargement sont transmis au système d'arrière-plan du partenaire contractuel client.

Dans le cas d'un compte prépayé (((eAutorisation de paiement : Pour les autorisations de compte prépayé créditées sur un compte de crédit du client, le rechargement du compte du client est contrôlé par le système d'arrière-plan du partenaire contractuel client primaire.

Le partenaire contractuel client primaire est responsable de la facturation au client et procède à la compensation financière vis-à-vis de celui qui a réalisé le rechargement. Il n'est pas possible d'indiquer manuellement la quantité d'options de droits de transport à recharger.

Suite à l'autoload, une écriture de créance correspondant à la valeur des options d'autorisation de transport chargées est passée sur le compte de facturation enregistré pour le contrat client.

Autorisation de circulation automatisée / IN-OUT Entitlement

L'autorisation de circulation automatisée (ACA) autorise le client à utiliser les prestations des transports publics. Elle règle la manière dont le client compense financièrement l'utilisation des prestations. La condition préalable à l'utilisation de l'AFB est l'existence d'une (((eautorisation de paiement sur le support de l'utilisateur. L'AFB est donc un mode d'utilisation de l'(((e)autorisation de paiement. Au cours de l'utilisation de l'autorisation dans le cadre de la saisie des données d'entrée et de sortie dans les systèmes IN-OUT, une preuve de prestation est créée.

La caractéristique de l'AFB est qu'elle définit le cadre de l'utilisation ainsi que le calcul de la rétribution de la prestation. Les DE sont émis en tant que méthode de paiement basée sur un compte avec procédure prépayée (PEB) ou postpayée (POB) dans le système d'arrière-plan ou en tant que méthode de paiement basée sur un support d'utilisateur (WEB, peut être anonyme) dans les systèmes d'AC.

Identification de l'application qui se trouve sur le support de l'utilisateur. Comme il peut y avoir plusieurs applications sur une carte à puce par exemple, l'identifiant sert à pouvoir sélectionner la bonne application (dans ce cas, l'application de transport public).

L'outil ASM (Application and Security Management Tool) est le système central de service et de gestion pour le (((eTicket Allemagne). Il soutient les tâches essentielles du Scheme Manager pour la gestion des applications et de la sécurité dans le (((eTicket Allemagne) comme

- Portail de service pour l'enregistrement du (((eTicket Allemagne)

- Service client pour les opérateurs de transport et les fabricants

- Gestion des clients, des fabricants et des participants au (((eTicket Allemagne).

- Mise à disposition de documents KA

- Commande de composants de sécurité KA, traitement et vérification des commandes.

ainsi qu'une partie des processus de suivi de la sécurité.

et il représente le référentiel KA de l'éditeur de l'application (AHS). L'outil ASM est accessible via https://asmtool.eticket-deutschland.de/

Les méthodes de cryptographie asymétrique utilisent des paires de clés composées d'une clé publique (en anglais public key) et d'une clé privée (en anglais private key). La clé publique n'est pas secrète, elle doit être connue du plus grand nombre possible d'autres utilisateurs. Elle permet d'effectuer des opérations publiques, c'est-à-dire de crypter des messages ou de vérifier des signatures numériques. Dans ce contexte, il est important qu'une clé publique puisse être attribuée de manière univoque à un utilisateur. Ceci est garanti par un certificat. Pour décrypter un texte crypté ou signer un message, la clé privée est nécessaire. Contrairement aux procédures symétriques, dans lesquelles plusieurs utilisateurs se partagent une clé symétrique, dans les procédures asymétriques, seul un utilisateur dispose de la clé privée (secrète). C'est cette circonstance qui permet d'attribuer clairement une signature à un utilisateur.

Le partenaire contractuel client exécutant (aKVP) autorise l'exécution d'une action avec un support d'utilisateur sur l'un de ses terminaux. Pour ce faire, il doit être connecté au service de listes d'actions et à la gestion des actions du responsable du produit via des listes d'actions. Il peut être en même temps partenaire contractuel client mandataire (bKVP).

Il peut y avoir plusieurs entités autorisées par l'éditeur de l'application à créer l'application sur un support utilisateur conformément à la spécification donnée et/ou à l'activer pour l'utilisation. L'édition peut également se faire par le biais de la distribution. Elle se fera toujours par l'intermédiaire d'un partenaire contractuel client. L'application sur le support utilisateur est également appelée application de transport public.

En cas d'autorisation d'unités de valeur : Recharge automatique avec une quantité convenue d'unités de transport public pour un contrat client existant en fonction de la réalisation de critères convenus contractuellement (par ex. atteinte ou non d'un montant minimum). Cela se produit pour les unités de transport public stockées dans le support d'utilisateur à chaque terminal d'acceptation qui détecte que le montant de chargement minimum n'est pas atteint et qui prend en charge la fonction Autoload. Tous les montants de chargement sont transmis au système d'arrière-plan du partenaire contractuel client.

Dans le cas d'un compte prépayé (((eAutorisation de paiement : Pour les autorisations de compte prépayé créditées sur un compte de crédit du client, le rechargement du compte du client est contrôlé par le système d'arrière-plan du contractant client primaire.

Le partenaire contractuel client primaire est responsable de la facturation au client et procède à la compensation financière vis-à-vis de celui qui a réalisé le rechargement. Il n'est pas possible d'indiquer manuellement la quantité d'options de droits de transport à recharger. Suite à l'autoload, une écriture de créance correspondant à la valeur des options d'autorisation de transport chargées est passée sur le compte de facturation enregistré pour le contrat client.

L'autorisation de circulation automatisée (ACA) autorise le client à utiliser des prestations de transport public. Elle règle la manière dont le client compense financièrement l'utilisation des prestations. La condition préalable à l'utilisation de l'AFB est l'existence d'une (((e) autorisation de paiement sur le support de l'utilisateur. L'AFB est donc un mode d'utilisation de l'(((e)autorisation de paiement. Au cours de l'utilisation de l'autorisation dans le cadre de la saisie des données d'entrée et de sortie dans les systèmes IN-OUT, une preuve de prestation est créée.

La caractéristique de l'AFB est qu'elle définit le cadre de l'utilisation ainsi que le calcul de la rétribution de la prestation. Les DE sont émis en tant que méthode de paiement basée sur un compte avec procédure prépayée (PEB) ou postpayée (POB) dans le système d'arrière-plan ou en tant que méthode de paiement basée sur un support d'utilisateur (WEB, peut être anonyme) dans les systèmes d'AC.

Une autorisation se base sur des données enregistrées dans une application qui autorisent l'utilisation d'un service de transport public. Une autorisation se compose entre autres d'un identifiant unique et d'une période de validité. Ces données déposées dans l'application peuvent prendre la forme d'un billet électronique ou d'une (((autorisation de paiement électronique). Un billet électronique représente une autorisation au sens d'un droit de circulation.

L'(((autorisation de paiement électronique utilise les mêmes structures de données sur le support de l'utilisateur, mais n'est pas encore une autorisation de circulation, mais seulement la base et la condition pour l'utilisation dans les systèmes IN-OUT (et peut y être utilisée comme autorisation de circulation automatisée (AFB)). L'autorisation proprement dite pour le trajet en cours n'est créée que par une procédure d'enregistrement avec cette (((autorisation de paiement électronique) utilisée ensuite comme AFB.

Si l'autorisation est un titre de transport électronique (EFS), elle contient d'autres informations tarifaires (produit, validité géographique, etc.). L'EFS peut être anonyme ou lié à une personne. Anonyme signifie qu'il suffit de posséder l'EFS et que tout le monde peut l'utiliser. Lié à une personne signifie que le FSE ne peut être utilisé que par une personne déterminée. Pour un FSE lié à une personne, des moyens d'identification supplémentaires sont utilisés lors du contrôle.

S'il s'agit d'une (((autorisation de paiement électronique, le type détermine si elle est basée sur un compte (avec option prépayée ou postpayée) ou si elle est utilisée en relation avec des unités de valeur sur le support de l'utilisateur. Pour l'((autorisation de paiement électronique, il existe une distinction anonyme / non anonyme. Les (((autorisations de paiement anonymes ne sont possibles que dans la variante des unités de valeur sur le support de l'utilisateur sans la fonction Autoload (qui nécessite un compte).

Les (((autorisations de paiement électronique basées sur un compte ne sont jamais anonymes, car l'identité du client est connue dans le système d'arrière-plan.

Le partenaire contractuel client mandant (bKVP) initie une action (pour une interaction ultérieure avec un média utilisateur) pour son client en envoyant un ordre d'action au service de liste d'actions du responsable du produit.

Dans le secteur des transports, le contrat de transport est un contrat qui a pour objet le transport de personnes (éventuellement plus des bagages). Dans les transports publics, c'est presque toujours le contrat de transport de personnes qui s'applique. Le mode de règlement de la créance du client pour la prestation de transport, c'est-à-dire le moyen de paiement utilisé.

Une autorité de certification (CA) est une organisation qui émet des certificats numériques. Un certificat numérique sert à attribuer une certaine clé publique à une personne ou à une organisation (titulaire du certificat). Cette attribution est authentifiée par l'autorité de certification qui y appose sa propre signature numérique.

L'autorité de certification porte ainsi la responsabilité de la mise à disposition, de l'attribution et de l'assurance de l'intégrité des certificats qu'elle délivre. L'AC agit ainsi en tant que tiers de confiance (Trusted Third Party) vis-à-vis du titulaire du certificat et de la partie qui se fie à l'authenticité du certificat. L'AC constitue le noyau d'une infrastructure à clé publique.

Le check-in après la poursuite du trajet est l'exécution d'un nouveau check-in après un check-in check-out déjà effectué suite à un changement de train. Le terminal détermine le check-in après la poursuite du trajet selon les instructions du responsable du produit dont le calcul du tarif est à la base du trajet/de la chaîne de trajets, par ex. en reconnaissant Check-InOrt = Check-Out-Ort (précédent) + critère de temps dans lequel un changement est accepté).

Voir également le système IN-OUT.

Les mécanismes qui, dans le monde des cartes à puce, règlent l'envoi et la réception de données entre le terminal et la carte à puce. Ils décrivent en détail les couches de protocole OSI utilisées, l'échange de données en cas de bon fonctionnement, les mécanismes de détection d'erreurs et les mécanismes de réaction en cas d'erreurs.

Le clearing (de créances) crée les conditions nécessaires à la réalisation d'une compensation de prestations entre les instances concernées. Sur la base des données de prestations comprimées mises à disposition, le clearing peut rassembler les données de facturation pour un utilisateur individuel, qui permettent en fin de compte une compensation des créances.

1) Collecte et tri des données.

2. transmission des données (réseau)

3. vérification des données (clarification)

(voir prestataire de services de transport public / PT Service Operator)

Les produits EFM sont définis par le responsable de produit et peuvent représenter chacun un ou plusieurs produits tarifaires pour l'utilisation dans la gestion électronique des billets. Ils doivent avoir un numéro unique pour ce responsable de produit et doivent être uniques dans tout le système EFM avec l'ID d'organisation du responsable de produit.

Un produit EFM est défini en termes de

- règles d'utilisation

- la fixation des prix

Le produit EFM détermine en même temps, en tant que modèle de produit, comment les paramètres du produit doivent être déposés sur le support utilisateur sous forme d'éléments de données spécifiés. En outre, il définit comment

- le calcul du prix doit être effectué à l'aide de ces paramètres

- qu'un contrôle automatique est effectué à l'aide des données dans l'autorisation

- le contrôle et le calcul automatique des prix dans les systèmes IN-OUT doivent être effectués à l'aide des données.

Le billet électronique décrit un titre de transport complet déposé sur un support client, qui (après une validation éventuellement nécessaire) peut être utilisé sous cette forme par un passager pour un voyage dans les transports publics, la validité spatiale et temporelle étant fixée au début de l'utilisation et ne pouvant plus être modifiée ultérieurement.

Un processus élémentaire désigne un ensemble techniquement cohérent de transaction(s), d'actions, de messages et de contrôles qui peuvent être répartis sur différents systèmes et qui sont attribués à des cas d'utilisation individuels. Un processus élémentaire contient donc en règle générale plusieurs cas d'utilisation.

Les applications et les autorisations peuvent être débloquées et réutilisées dans le cadre de (((eTicket Allemagne). Le déblocage se fait sur la base d'un changement de statut de l'application ou de l'autorisation sur le support de l'utilisateur, qui repasse au statut "actif". L'application ou l'autorisation est alors à nouveau utilisable.

Le déblocage n'est possible que sur les terminaux autorisés du partenaire contractuel du client.

Si le marquage de blocage est retiré à l'aide d'un déverrouillage dans une application, une preuve de déverrouillage est envoyée au système d'arrière-plan du partenaire contractuel client. Si le marquage de blocage est retiré à l'aide d'un déblocage dans une autorisation, une preuve de déblocage est envoyée au système d'arrière-plan du partenaire contractuel client et également au responsable du produit.

L'annulation dans le cadre des transports publics signifie l'utilisation d'un ticket qui était prévu pour une utilisation unique à un moment quelconque, correspondant au produit tarifaire du ticket. L'utilisation du ticket est attestée par un tampon (ticket papier) ou une preuve électronique dans un billet électronique, ce qui entraîne à son tour l'annulation, car le ticket ne peut plus être utilisé une seconde fois. D'autre part, le billet n'est valable pour le trajet en cours que par cette opération.

La saisie signifie l'enregistrement des opérations In-Out (par ex. Check-In et CheckOut) dans les systèmes IN-OUT ainsi que leur collecte et leur transmission au responsable du produit. Une preuve à cet effet est déposée sur le support de l'utilisateur. Dans ce contexte, il s'agit toujours de la saisie technique de données pour le calcul des prestations, et non pas d'une saisie statistique du nombre de passagers, etc. Le prestataire de services de transport public est responsable de la saisie. En effet, celui-ci doit être en mesure de prouver la prestation qu'il fournit et doit donc effectuer un relevé. Le prestataire de services de transport public remplit ainsi une partie du rôle de collecte et de transmission (Collection and Forwarding) selon la norme ISO 24014 et est responsable des données de collecte de prestations et de recettes issues de l'utilisation des autorisations lors de l'utilisation des services de transport des entreprises de transport public.

Remarque : les opérations de contrôle peuvent également être considérées comme une saisie, mais constituent un cas d'application à part entière, voir Contrôle.

Données générées par les terminaux de saisie et transmises au système d'arrière-plan.

Terme générique pour tous les types d'appareils périphériques destinés à enregistrer l'utilisation des services de transport dans les véhicules et aux arrêts dans les systèmes IN-OUT. Ils font partie du groupe des terminaux d'acceptation.

Une augmentation du prix du transport (EBE) est due lorsqu'un client ne peut pas présenter un titre de transport (billet) valable.

s. Autorisation / Entitlement

Moment de la détermination tarifaire (automatique) de la valeur de la prestation de transport public (détermination du prix) et du débit de la valeur conformément au mode de paiement enregistré (moment du paiement). Les processus de détermination du prix et de paiement sont découplés, même si, en particulier dans le cas de la détermination du prix pre-priced, le paiement a lieu immédiatement après. Selon le tarif, seuls certains modes de paiement sont possibles.

Il existe les variantes de détermination du prix suivantes :

- pre-priced : le prix du billet est déterminé avant le trajet ou le voyage. En général, cela signifie qu'un billet est acheté avant le début du voyage. Les modes de paiement valables sont :

o débit sur une (((e) autorisation de paiement

o paiement immédiat en espèces,

o débit sur une carte de crédit, une carte de débit, une carte de paiement, etc.

- trip-priced : le prix du trajet est fixé directement après la fin d'un trajet (en général à l'échéance du CheckOut). Le mode de paiement valable dans le cadre de l'application centrale est le suivant

o Débit sur une autorisation d'unité de valeur (WEB)

- post-priced : le prix du trajet est fixé un certain temps après le voyage, généralement dans un système d'arrière-plan. Ainsi, le paiement d'un service de transport public n'a lieu qu'un certain temps après l'utilisation du service. Seule la méthode post-priced permet de calculer le meilleur prix pour le client. valide

Les modes de paiement sont :

o débit sur le compte

o compte postpayé ou compte prépayé du partenaire contractuel du client

Remarque : le moment du paiement n'a rien à voir avec le mode de paiement du client à l'aide de son (((autorisation de paiement en ligne (là aussi, les termes prepaid et postpaid sont utilisés). Comme on le voit dans le cas de la procédure post-priced, un paiement post-priced peut être effectué via un compte prépayé et l'autorisation de((e)paiement prépayé correspondante.

Un trajet est l'utilisation d'un moyen de transport de la montée à la descente.

Une section de trajet est une partie d'un trajet. Elle peut être caractérisée par la mention de deux arrêts.

Le compteur d'erreurs de manipulation est incrémenté en cas de saisie d'un PIN erroné. En règle générale, le code PIN peut être saisi trois fois de manière erronée, après quoi l'objet protégé par le code PIN (ici, le plus souvent, une carte à puce) est bloqué et doit être débloqué à l'aide d'un code PUK. Si le PIN est saisi correctement, le compteur d'erreurs de manipulation est remis à 0.

Le partenaire contractuel tiers effectue des transactions avec des applications ou des autorisations de partenaires contractuels primaires pour lesquelles il est autorisé par les conditions d'utilisation. Cela s'applique en premier lieu à l'utilisation de (((autorisations de paiement électronique émises par le contractant primaire et qui doivent être utilisées chez le contractant tiers pour l'utilisation de services de transport public (par exemple, achat d'un billet dans l'environnement du contractant tiers avec une (((autorisation de paiement électronique du contractant primaire.

Voir aussi le modèle de rôle dans le Spec-Main (pour KA 1.X Spec HD BOM).

Un centre de services partagés (CSP) représente un système d'abonnés d'arrière-plan qui prend en charge et traite les tâches spécifiques aux rôles des abonnés connectés à un poste central. De plus, les messages prétraités y sont transmis aux systèmes d'abonnés KA via le réseau d'interopérabilité (fonction de médiation).

Tous les systèmes informatiques d'une gestion électronique des titres de transport qui assurent le traitement et la gestion des données à partir de la hiérarchie des terminaux d'acceptation.

L'initialisation de l'application de transport public crée la structure de données définie pour l'application sur la puce et remplit les champs de données avec des valeurs prédéfinies. L'état de l'application reçoit la valeur initiale "initialisé". L'application n'est pas encore utilisable dans cet état. Pour cela, elle doit encore être activée. Voir à ce sujet Activation de l'application.

Type de terminal d'acceptation dans le système de gestion des titres de transport d'un exploitant de système, dans lequel une preuve (partielle) de prestation est créée automatiquement dans l'application au début du trajet et complétée ou ajoutée automatiquement au cours du trajet (généralement à la fin du trajet). Les représentants du système sont :

- Systèmes de check-in/check-out (CICO),

- les systèmes Be-in/Be-out (BIBO).

- Systèmes d'enregistrement/de sortie (CIBO)

Le justificatif de performance (partiel) créé automatiquement au début du trajet est ici considéré comme la preuve d'une autorisation de circuler valable. Dans les systèmes BIBO, le justificatif de performance est complété par l'inscription sur le support de l'utilisateur du prochain arrêt après le départ du moyen de transport.

L'interopérabilité est une caractéristique d'un produit ou d'un système dont les interfaces sont entièrement connues, de sorte qu'il peut fonctionner avec d'autres produits ou systèmes, actuels ou futurs, sans aucune restriction, que ce soit au niveau de la mise en œuvre ou de l'accès.

La description ci-dessous se réfère à la définition de l'interopérabilité au sein de (((eTicket France) :

La garantie d'un voyage continu et de trajets ponctuels pour le voyageur en utilisant le même support utilisateur avec la même application dans les réseaux (systèmes de gestion des titres de transport) de toutes les entreprises de transport impliquées dans le contrat. Pour en savoir plus sur l'interopérabilité, cliquez ici.

Dans les systèmes interopérables, un grand nombre de données doivent être échangées entre les différents partenaires du système dans différents systèmes individuels. Le réseau d'interopérabilité se charge de cette tâche. Il dispense les unités opérationnelles (éditeur d'application, service de contrôle et de liste de blocage, responsable de produit, partenaire contractuel client et prestataire de services) d'être informées des détails du transfert de données.

Le réseau d'interopérabilité (ION) lui-même désigne l'ensemble du réseau qui est nécessaire, logiquement et physiquement, pour envoyer des messages entre les systèmes des participants dans toute l'Allemagne.

Le détenteur de la carte est la personne qui a le pouvoir effectif de disposer de la carte. Si la carte est utilisée, le détenteur de la carte devient l'utilisateur de la carte. Le titulaire de la carte est le propriétaire de la carte. Il n'est pas nécessairement le détenteur de la carte.

La notion de type de carte est utilisée dans l'AC pour distinguer les différentes versions techniques d'une carte à puce (p. ex. carte de crédit, carte avec émulation Mifare, etc).

Le nom Kernapplikation (KA) désigne le standard allemand pour les systèmes de gestion électronique des titres de transport chez différents exploitants de transports publics ou de systèmes dans les versions 1 et 2. Le nouveau nom (((etiCORE se réfère à la version 3. Les deux standards englobent la sécurité, la certification, le concept organisationnel et les interfaces système pertinentes dans la billetterie électronique, qui permet l'utilisation interopérable d'une application de transport public sur un support utilisateur.

Elle définit

- la réalisation de la spécification sur une puce dans un support utilisateur et son interface avec les terminaux d'acceptation nécessaires

- la description des interfaces nécessaires entre les terminaux d'acceptation et les systèmes d'arrière-plan

- la description des interfaces nécessaires entre les systèmes d'arrière-plan des systèmes de gestion des billets de différents niveaux et des instances concernées

- la preuve de la conformité à la norme et de la sécurité par une procédure de certification

La gestion des clés concerne l'ensemble du traitement des clés cryptographiques, c'est-à-dire la création, la distribution, la gestion, le stockage, le remplacement et la surveillance des clés cryptographiques (voir aussi Clé symétrique/Cryptographie asymétrique).

En Allemagne, les tâches mentionnées sont assurées par le Scheme Manager (d'après qui ne couvre toutefois qu'un aspect partiel) et prises en charge par une instance centrale, le sous-rôle du gestionnaire de sécurité. Dans (((etiCORE, la gestion des clés symétriques n'est pas nécessaire dans les systèmes partenaires du responsable du produit et du partenaire contractuel client.

Le contrôle vérifie que toutes les conditions requises chez le client / l'usager pour l'utilisation d'un service de transport public sont remplies :

- support client lisible,

- application valable (y compris contrôle de la liste de blocage des applications)

- autorisation valable (y compris vérification de la liste de blocage des autorisations)

- produit valable (validité tarifaire)

Elle est prioritairement dans l'intérêt du prestataire de services de transport public qui facture ses services sur la base de justificatifs de performance. Si l'une de ces conditions n'est pas remplie, le contrôle initie la majoration du prix du transport. Le contrôle initie en outre le blocage d'une application ou d'une autorisation sur le support client si des entrées de blocage correspondantes sont trouvées sur la liste de blocage. Le blocage sur le support utilisateur peut être effectué sans SAM à partir de 2GSI / (((etiCORE).

Dans 1GSI / KA 1.X, une preuve de contrôle est écrite sur le support utilisateur en plus de l'envoi au responsable du produit, à partir de 2GSI / (((etiCORE, la preuve de contrôle n'est plus envoyée qu'au responsable du produit. Ainsi, à partir de 2GSI / (((etiCORE, le contrôle est possible sans SAM. Au sens de la norme ISO 24014, le contrôle peut être compris comme une partie de la saisie, mais il constitue un cas d'application à part entière.

Le service de listes de contrôle et de blocage (KOSE) propose des listes d'entrées de blocage de

- autorisations

- Applications

- Modules d'application sécurisés (SAMs)

- Clés

- Organisations

Les entrées dans les listes dédiées indiquent que l'instance référencée est volée, compromise, invalide, etc. Pour toutes ces instances, de nouvelles commandes peuvent être exécutées pour ajouter une entrée à ces listes réactives ou pour supprimer une entrée de ces listes réactives :

- par le Scheme Manager en ce qui concerne les organisations, les SAM et les clés (dans (((etiCORE, uniquement les clés d'authentification))

- par les partenaires du contrat client en ce qui concerne les applications et les autorisations.

En outre, dans le cadre du Collecting and Forwarding (voir ISO 24014-1), les preuves de blocage (qui se rapportent soit à une autorisation soit à une application) sont traitées en étant collectées par les fournisseurs de services et mises à la disposition des responsables de produits (autorisations) et de l'éditeur d'applications (applications). Voir le modèle de rôles dans Spec Main.

Support de l'application. Voir aussi support utilisateur.

Les données clients sont le terme générique pour désigner les préférences et le profil des clients.

Données individuelles du client, sélectionnables, qui sont enregistrées dans l'application sur le support du client et qui peuvent par exemple servir à accélérer le dédouanement. Elles ne sont pas automatiquement pertinentes pour le contrat. Il s'agit de préférences de ticket.

Ensemble des données de base personnelles décrivant le client, qui sont stockées dans l'application sur le support client. Grâce à sa structure de données spécifiée, le profil client peut être interprété de la même manière pour toutes les interactions avec l'application. Son utilisation peut toutefois être spécifique à l'opérateur.

Le service client est défini dans la norme ISO 24014-1 et réalise pour chaque client une information globale et une gestion des plaintes en rapport avec l'application centrale VDV, y compris les supports d'utilisateurs volés ou endommagés. Ce service comprend des fonctions de centre d'appel, un service Internet et peut être assuré par des points de service régionaux.

Un contrat client au sens du (((eTicket Allemagne) représente une relation entre l'opérateur de transport qui fournit un service au client et le client. Le contrat client décrit les conditions dans lesquelles le client peut utiliser les prestations de service proposées par l'opérateur de transport. En même temps, le client se voit accorder le droit d'utiliser un service. Le contrat client règle la détermination du prix du trajet et la facturation entre un partenaire contractuel client et un client. Le contrat client détermine en premier lieu les paramètres tarifaires applicables aux utilisateurs.

Le contrat client est toujours qualifié par l'ID d'organisation du partenaire contractuel client. Le contrat client est enregistré sous forme électronique en tant qu'autorisation (en tant qu'((autorisation de paiement électronique ou titre de transport électronique) sur la base d'un produit EFM défini par le responsable du produit sur l'application de transport public.

Le rôle de contractant client est un rôle spécifique dans l'application de base. Il se compose de plusieurs rôles définis dans la norme ISO 24014-1 :

- Product Retailer

- Application Retailer

- Service client

- Fournisseur d'identité

- Fournisseur de compte

- Payment Provider

Le partenaire contractuel client régule les processus de vente du client en tenant compte des dépendances contractuelles vis-à-vis du Scheme Manager et du responsable produit des différents services de mobilité. Le partenaire contractuel client est notamment responsable de la comptabilité, de la billetterie et de la facturation des différents services de mobilité vis-à-vis du client.

Il assume ainsi les rôles de Product Retailer, Application Retailer (Instance Issuer) et Account Provider. En tant que fournisseur de compte, il fait appel aux services des fournisseurs de paiement de son choix avec lesquels il est lié par contrat. Le partenaire contractuel client peut intervenir dans le rôle de partenaire contractuel client primaire ou dans le rôle de partenaire contractuel client tiers. Voir le modèle de rôles dans Spec Main.

L'unité de personnalisation du partenaire contractuel du client encapsule la communication entre le support de l'utilisateur et le SAM. Elle se compose donc au minimum d'un lecteur/enregistreur avec SAM.

Si un support d'utilisateur doit être imprimé sous la forme d'une carte à puce, l'imprimante correspondante fait également partie de l'UP KVP. Par exemple, une machine de lettershop chez un personnalisateur de masse constitue en fin de compte également une UP KVP.

L'unité de vente du partenaire contractuel client (UCP) met à disposition le logiciel pour la sélection des applications pour la personnalisation, des autorisations ainsi que la communication avec le système de base de référence et met à disposition les composants d'entrée et de sortie nécessaires (moniteur/clavier).

Le relevé des prestations représente les données de prestations enregistrées sur le support de l'utilisateur pour contrôle, qui décrivent l'utilisation des prestations par le client dans le système IN-OUT.

Premier niveau de sécurité dans l'architecture de sécurité de l'application principale VDV (dans le (((eTicket Allemagne)). Le niveau 1 utilise un nombre très limité d'identifiants d'organisation qui sont utilisés à titre d'exemple pour tous les participants dans leurs rôles pour la certification des composants du système. Ces identifiants d'organisation spécifiques sont conçus de telle sorte qu'ils ne sont reconnus par aucun système actif. Pour les tout premiers tests lors du développement de composants de système, il est recommandé de travailler dans ce niveau 1.

Deuxième niveau de sécurité dans l'architecture de sécurité de l'application principale VDV (dans le (((eTicket Allemagne)). Au niveau 2, la génération et l'utilisation de tous les composants de sécurité KA (clés symétriques / asymétriques, SAM et support utilisateur) s'effectuent avec des ID d'organisation qui sont attribuées en complément des ID d'organisation actives ou de niveau 3 attribuées aux participants.

Dans la version 1.X de KA, le premier bit de l'ID d'organisation de 2 octets est remplacé. Ainsi, une valeur de 8000 en hexadécimal ou de 32768 en décimal est ajoutée à l'ID d'organisation de niveau 3. Par exemple, l'organisation 5600 en décimal ou 15E0 en hexadécimal devient alors l'ID d'organisation 95E0 en hexadécimal ou 38368 en décimal au niveau 2.

Dans (((etiCORE, le niveau n'est plus contrôlé par l'ID de l'organisation elle-même (qui n'est pas fixée à 2 octets), mais par le certificat utilisé. Ainsi, les ID d'organisation sont les mêmes dans le niveau 2 et le niveau 3, et seule la gestion de la sécurité ou l'émission des certificats permet de contrôler la manière dont l'environnement système actuel peut être utilisé.

Troisième niveau de sécurité (le plus élevé) dans l'architecture de sécurité de l'application principale VDV dans le (((eTicket Allemagne). Au niveau 3, la génération et l'utilisation de tous les composants de sécurité KA (clés symétriques / asymétriques, SAM et support utilisateur) s'effectuent avec les identifiants d'organisation de niveau 3 que les participants utilisent dans leurs systèmes KA pour une identification, une authentification, un cryptage et une sécurisation de transaction uniques.

Ici, tous les composants de sécurité sont protégés pour garantir de bout en bout les intérêts des participants et ne sont pas accessibles à des tiers. Le niveau 3 est réservé à l'exploitation effective. En mode actif du (((eTicket Allemagne), seuls les objets de valeur (par exemple les (((eautorisations de paiement)) qui ont été créés avec des identifiants d'organisation de niveau 3 sont utilisés et reconnus. Seuls les certificats de niveau 3 peuvent être utilisés pour les (((etiCORE Standards).

Une preuve enregistre de manière authentique une transaction au niveau du support de l'utilisateur. Il peut s'agir de la délivrance d'une autorisation, d'un check-in ou d'un check-out, d'une preuve de contrôle, d'un blocage, d'un déblocage, d'une validation, d'un chargement d'unités de valeur, etc.

Les versions de secours sont utilisées pour limiter les pannes et les dommages (financiers) au cas où une clé serait compromise. Cela signifie en fait qu'en plus des clés respectives, des clés de secours sont également enregistrées dans l'application lorsque celle-ci est personnalisée. Il est possible de basculer sur ces clés de secours pendant l'utilisation.

A partir de (((etiCORE), le terme n'est plus utilisé car un autre mécanisme est utilisé pour l'utilisation d'une autre clé suite à une compromission de clé. Voir à ce sujet Clé symétrique.

L'utilisateur est en possession du support d'utilisation et est le voyageur (Passenger) au sens de la norme ISO 24014-1. Il utilise la prestation de transport public d'un produit tarifaire donné. Contrairement au client, l'utilisateur peut également participer anonymement à (((eTicket-Allemagne).

s. Média client / Customer Medium.

Les paramètres du tarif utilisateur peuvent être modifiés par l'utilisateur de l'application sur les terminaux par rapport à un contrat de transport valide pour un trajet auquel les paramètres modifiés s'appliquent alors (par exemple, règles de covoiturage ou changement de classe de service).

Les compteurs d'utilisation sont utilisés pour accorder au client des tarifs spéciaux sur la base des prestations de transport qu'il utilise lors d'une détermination automatisée du prix du billet. Lors de la détermination du prix du billet post-priced, un scénario de meilleur prix ou de bonus peut être réalisé sans compteur d'utilisation.

Dans le cas d'une tarification au trajet combinée à l'utilisation d'une autorisation d'unité de valeur, le compteur d'utilisation est nécessaire pour accorder des tarifs spéciaux sur les prestations de transport utilisées (par ex. calcul d'un billet journalier à partir du quatrième trajet individuel).

s. Cryptographie asymétrique / Asymmetric Cryptography

Le prestataire de services de transport public fournit des services de transport à un client qui a acquis une autorisation appropriée pour utiliser ces services. Le contrat de transport est conclu entre le prestataire de services de transport public et un usager/voyageur lors de l'embarquement dans le moyen de transport.

Le prestataire de services acquiert, dans le cadre d'une relation contractuelle (((contrat de participation eTicket)), le droit de participer au système EFM auprès du gestionnaire du système. Le prestataire de services de transport public conclut des contrats avec les responsables de produits pour l'acceptation des produits et pour le paiement des prestations de transport fournies, ainsi qu'avec les partenaires contractuels clients pour la compensation des créances générées (via la compensation des créances).

Voir également le modèle de rôle dans la Spec-Main (pour KA 1.X Spec HD BOM).

Unités de valeur payées par le client et affectées à un usage spécifique, qui servent à utiliser des services de transport sans argent liquide. Les unités de valeur de transport public sont acquises contre des moyens de paiement valables et acceptés auprès de services de transport public autorisés en conséquence, stockées dans l'application de transport public et successivement débitées de la mémoire en fonction des prestations (de transport) utilisées aux terminaux de transport public autorisés. Les unités de valeur de transport public correspondent dans leur utilisation à un contingent de trajets multiples pour le transport public.

L'ID d'organisation identifie clairement une organisation dans l'ensemble du domaine d'application de l'application principale. L'ID d'organisation se compose du numéro d'organisation qui est attribué par l'enregistrement du Scheme Manager (VDV ETS) via l'outil ASM lors de la conclusion d'un (((contrat eTicket. Les organisations pourvues d'un ID sont des personnes morales, typiquement des entreprises de transport et des associations. Dans des cas exceptionnels, il peut s'agir d'unités d'exploitation clairement délimitées d'une grande entreprise.

Un numéro d'identification personnel (NIP) est un code d'accès numérique (ou, moins couramment, alphanumérique) utilisé lors de l'authentification d'un utilisateur accédant à un système.

Spécialement utilisé dans le cadre de l'application de base : Code secret à quatre chiffres qui peut être utilisé pour lire des données client sur le support de l'utilisateur. Ces données client ne peuvent être lues que soit de manière authentique par des terminaux autorisés, soit par le client lui-même à l'aide de son code PIN.

La personnalisation au sens de (((eTicket Allemagne) signifie l'introduction de données personnelles dans l'application du support de l'utilisateur. Il en résulte un profil client et, le cas échéant, des préférences client. Les processus techniques à cet effet sont décrits dans la spécification du support utilisateur.

Le terme "lié à une personne" est généralement utilisé dans le contexte des autorisations et signifie qu'une autorisation n'est valable que pour une personne déterminée et n'est pas transférable.

L'infrastructure à clé publique (PKI) désigne un système capable d'émettre, de distribuer et de vérifier des certificats numériques. Les certificats émis au sein d'une PKI sont utilisés pour sécuriser la communication assistée par ordinateur. La PKI est utilisée dans l'environnement de la cryptographie asymétrique.

Désigne un compte sur lequel les prestations de transport public utilisées par le client sont facturées via le droit de paiement prépayé (PEB). Pour l'option Autoload, lorsqu'une valeur seuil convenue contractuellement est atteinte, une somme d'argent convenue peut être rechargée contre un compte client d'un établissement de crédit connu du partenaire contractuel du client. Les services de transport public utilisés via l'autorisation sont collectés indépendamment des données personnelles du client et facturés en temps réel via ce compte. Il existe au moins un contrat client pour chaque compte prépayé.

Remarque : la mise en place d'une procédure de paiement prépayé anonyme (sans autoload) serait en principe possible, mais n'est actuellement pas prévue dans le cadre de l'application principale.

Le partenaire contractuel client primaire émet une application ou une autorisation. Son ID d'organisation est saisi dans l'application ou l'autorisation afin de permettre l'attribution de l'application ou de l'autorisation au partenaire contractuel client primaire qui l'a émise.

Désigne un compte par lequel les services de transport public utilisés par le client sont réglés par le biais de l'autorisation de paiement postpaid (((e) (POB) sur facture ou par le biais d'un compte client d'un établissement de crédit connu du contractant client primaire. Les services de transport public utilisés par le biais de l'autorisation sont collectés indépendamment des données personnelles du client et sont facturés via ce compte à une date convenue par contrat. Il existe au moins un contrat client pour chaque compte postpayé.

Par nature, la mise en place d'une procédure de paiement post-payé n'est pas possible de manière anonyme.

Le terme produit est utilisé dans l'application principale dans le sens d'un produit tarifaire de transport public ou d'un produit EFM.

La compensation des produits (PCL) est un système central qui constitue un serveur tarifaire pour toute l'Allemagne et qui connaît et peut calculer tous les tarifs des participants connectés grâce à des modules tarifaires selon PKM. Le Produktclearing détermine les tarifs et les prix corrects pour la chaîne de déplacement du client.

Pour le calcul des prix des billets, le PCL utilise les modules tarifaires selon PKM. Ce standard ouvert pour la représentation numérique des données tarifaires fait partie de l'application centrale de VDV et permet non seulement de renseigner sur les demandes liées au produit, mais aussi de calculer le produit tarifaire correct en fonction du trajet sur la base des paramètres tarifaires de l'utilisateur indiqués.

Tous les responsables de produits impliqués dans (((eTicket Deutschland) mettent leur module tarifaire actuel à disposition du système. Il en résulte un point central pour toutes les données tarifaires en Allemagne.

Le Responsable de produit développe des produits EFM à partir de ses tarifs pour des services de transport dans une ou plusieurs zones géographiques dans lesquelles différents prestataires de services de transport public offrent des services de transport. Le contrat de participation règle les modalités nécessaires entre le responsable du produit, les partenaires contractuels clients et les prestataires de services de transport public. Le responsable du produit acquiert, dans le cadre d'une relation contractuelle, le droit de participer aux systèmes EFM et d'y enregistrer ses produits auprès du Scheme Manager. Il reçoit du Scheme Manager les identifiants et informations nécessaires à la gestion de ses jetons, droits et modules de sécurité.

Dans le cadre de la gestion de la sécurité, le responsable de produit autorise les partenaires contractuels clients à émettre des autorisations. Le responsable de produit autorise les partenaires contractuels clients à vendre ses produits.

Voir aussi le modèle de rôle dans Spec Main (pour KA 1.X Spec HD BOM)

L'autorisation de référence met à disposition une structure définie qui peut être utilisée aussi bien comme autorisation de circulation automatisée que pour un billet électronique. D'une part, elle représente un modèle recommandé pour une autorisation de circulation automatisée avec des structures spécifiques au produit bien définies pour une utilisation interopérable.

D'autre part, l'autorisation de référence pour un billet électronique est une proposition avec des structures prédéfinies spécifiques au produit, qui peuvent être utilisées par les responsables du produit lors de la mise en œuvre des billets électroniques. Le TLV-EFS offre une alternative un peu plus flexible et optimisée en termes de mémoire.

Le système de référence est un système imaginaire, le terminal de référence est un terminal imaginaire qui réunit des fonctionnalités de base définies. Ces fonctionnalités de base se retrouvent dans l'utilisation réelle de différents systèmes ou types de terminaux associés au système. Les fonctionnalités réalisées dans le système ou le terminal réel y sont mises en œuvre de manière analogue aux cas d'application dans les cahiers des charges des systèmes (à partir de (((etiCORE : KVP-Ref - prestataire de services.

Instance au sein de la Public Key Infrastructure auprès de laquelle des personnes, des machines ou des autorités de certification subordonnées peuvent demander des certificats. La RA vérifie l'exactitude des données contenues dans le certificat demandé et approuve la demande de certificat, qui est ensuite signée par l'autorité de certification (CA).

Le sous-rôle Enregistrement du Scheme Manager est responsable de la génération, de l'organisation et de la responsabilité des identifiants nécessaires dans le système pour une utilisation interopérable, ainsi que de la gestion des contrats nécessaires à l'organisation et au fonctionnement.

La version régulière d'une clé (symétrique) peut être utilisée tant que la clé n'est pas compromise. A partir de (((etiCORE, la terminologie n'est plus utilisée, car un autre mécanisme est utilisé pour l'utilisation d'une autre clé suite à une compromission de clé. Voir à ce sujet Clé symétrique. Voir aussi version de secours.

Le Scheme Manager est l'instance supérieure de (((eTicket Deutschland). Cette tâche est assurée par VDV ETS. Le Scheme Manager combine les rôles d'éditeur d'application, d'enregistrement et de gestionnaire de sécurité de la norme ISO 24014-1.

Il crée les règlements et les surveille. Il existe une fois dans le système et s'identifie clairement. De plus amples informations sont disponibles dans le modèle de rôle de la spécification principale.

Le registre des clés fait partie d'une fonction spéciale de l'application sur le support de l'utilisateur. Il est nécessaire en relation avec l'émission d'autorisations (dans ce contexte, on utilise le terme ambigu de multi-autorisations*).

Les clés utilisées peuvent être introduites de manière protégée dès l'édition de l'application pour le partenaire contractuel client émetteur et le responsable produit prévu. Ces clés dépendent de l'ID d'instance de l'application, mais pas d'un ID d'autorisation individuel. Si nécessaire, d'autres clés peuvent être introduites pour d'autres partenaires contractuels clients ou responsables de produits.

Lors de l'émission d'une autorisation, les références de clés nécessaires aux clés existantes sont alors saisies dans le registre des clés, des clés adaptées entre le support de l'utilisateur et le terminal pour l'émission d'une autorisation représentent une accélération considérable. L'autorisation délivrée dans une application avec registre de clés ne se distingue pas, du point de vue technique, d'une autorisation délivrée dans une application sans registre de clés.

A partir de (((etiCORE, en raison des processus cryptographiques plus rapides, l'utilisation d'un registre de clés n'est plus nécessaire dans le contexte de l'émission d'autorisations sous cette forme. Cependant, il existe un nouveau registre de clés utilisé pour l'authentification sous une forme similaire, dans lequel sont stockées les références aux générations de clés d'authentification, voir également Clé symétrique.

*Le terme multi-autorisations suggère qu'il pourrait s'agir d'autorisations multiples pouvant être utilisées pour différents services. Mais ce terme se réfère uniquement au fait que des clés peuvent être utilisées pour plusieurs autorisations afin de gagner du temps pour les processus cryptographiques lors de l'accès. La multi-autorisation elle-même n'est pas différente de l'autorisation normale.

Le Secure Application Module (SAM) est utilisé comme module de sécurité pour les contractants clients ou les prestataires de services et exécute les fonctions de sécurité des terminaux de vente et/ou des terminaux de contrôle qui communiquent directement avec les supports utilisateurs. Il peut également être utilisé pour vérifier les signatures de transaction générées avec le support utilisateur dans les systèmes d'arrière-plan.

Le Secure Crypto Environment (SCE) est un composant logique sur l'appareil mobile d'un passager qui est capable de recevoir (ou de générer) et d'utiliser des clés cryptographiques et de les lier de manière inaltérable à l'appareil mobile et à une application de billetterie.

La SCE doit être résistante à la lecture des clés et à la copie sur un autre appareil mobile et peut effectuer un contrôle d'authenticité des clés avec le backend. D'un point de vue technique, elle peut être implémentée, par exemple, sous la forme d'une bibliothèque intégrée dans une application de billetterie et utilisant les ressources de sécurité de l'appareil mobile, comme une mémoire de clés côté matériel.

L'architecture de sécurité de l'application principale comprend 3 niveaux de sécurité différents pour le test et l'exploitation réelle, qui se rapportent à l'utilisation des supports utilisateurs, au SAM, aux clés symétriques et asymétriques et aux certificats associés. Les niveaux de sécurité et les environnements de production associés chez le prestataire de services de sécurité sont totalement séparés afin de ne pas prendre de risques en matière de sécurité. Conformément aux niveaux de sécurité séparés, pour KA version 1.X, une entreprise participante reçoit deux identifiants d'organisation, un pour le niveau 2 et un pour le niveau 3. Pour (((etiCORE, les certificats correspondants sont utilisés pour les différents niveaux de sécurité.

La demande de blocage doit entraîner l'inscription d'un objet sur la liste de blocage correspondante par un tiers responsable. Selon l'objet, les parties prenantes sont différentes :

- Demande adressée au partenaire contractuel client responsable pour qu'il place une autorisation sur la liste de blocage. Cette demande peut être initiée par un autre partenaire contractuel client, un prestataire de services de transport public ou un responsable de produit.

- Demande adressée au partenaire contractuel client compétent pour placer une application sur la liste de blocage. Cette demande peut émaner d'un autre partenaire contractuel client, d'un prestataire de services de transport public ou de l'éditeur de l'application.

- Demande adressée à l'éditeur d'applications de placer un module d'application sécurisé, une clé (à partir de (((etiCORE, uniquement une clé d'authentification) ou une organisation sur la liste de blocage correspondante. Cela peut être initié par un autre partenaire contractuel client, un prestataire de services de transport public ou un responsable de produit.

La demande de suppression du blocage doit entraîner le retrait d'un objet de la liste de blocage correspondante par un tiers responsable. Selon l'objet, les parties prenantes sont différentes :

- Demande faite au partenaire contractuel client responsable de retirer une autorisation de la liste de blocage. Cette demande peut être initiée par un autre partenaire contractuel client, un prestataire de services de transport public ou un responsable de produit.

- Demande adressée au partenaire contractuel responsable pour retirer une application de la liste de blocage. Cette demande peut émaner d'un autre partenaire contractuel client, d'un prestataire de services de transport public ou de l'éditeur de l'application.

- Demande adressée à l'éditeur d'application de retirer un module d'application sécurisé, une clé (plus à partir de (((etiCORE)) ou une organisation de la liste de blocage correspondante. Cela peut être initié par un autre partenaire contractuel client, un prestataire de services de transport public ou un responsable de produit.

L'ordre de blocage sert à ajouter un objet à la liste de blocage correspondante. Selon l'objet à ajouter, il existe différents initiateurs :

- Le partenaire contractuel client compétent donne l'ordre d'ajouter une autorisation ou une application à la liste de blocage.

- Le Scheme Manager ordonne l'ajout d'un Secure Application Module ou d'une organisation à la liste de blocage.

- Le propriétaire de la clé (partenaire contractuel client, responsable de produit ou Scheme Manager) ordonne l'ajout d'une clé (à partir de (((etiCORE, uniquement le Scheme Manager en tant que propriétaire de la clé)) à la liste de blocage correspondante.

L'ordre de déblocage sert à retirer un objet de la liste de blocage concernée. Selon l'objet à retirer, il existe différents initiateurs :

- Le partenaire contractuel client responsable donne l'ordre de retirer une autorisation ou une application de la liste de blocage.

- Le Scheme Manager ordonne le retrait d'un Secure Application Module ou d'une organisation de la liste de blocage.

- Le propriétaire de la clé (client-partenaire contractuel, responsable de produit ou Scheme Manager) ordonne le retrait d'une clé (à partir de (((etiCORE, il n'est plus possible de demander la libération d'une clé par le Scheme Manager) de la liste de blocage correspondante.

Le motif de blocage indique la raison pour laquelle un blocage a été/doit être effectué.

Une liste de blocage se compose d'un ensemble d'entrées de liste de blocage pour un objet donné (autorisation, application, SAM, clé, organisation). Elle sert (après répartition correspondante dans les systèmes / terminaux) à détecter une utilisation non autorisée d'une application ou d'une autorisation à bloquer pour l'utilisation de services de transport.

Sur la base de la liste de blocage et de ses entrées de liste de blocage, un blocage physique (pour les autorisations et les applications) ou un blocage logique, ou encore le refus d'une autorisation ou d'une application (sur la base d'entrées de blocage SAM, de clé ou d'organisation) est effectué.

Une entrée dans la liste de blocage est créée par l'ajout d'un objet à bloquer (application, autorisation, organisation, SAM, clé) dans la liste de blocage.

Une preuve de blocage est générée en vérifiant l'application et les autorisations par rapport aux listes de blocage correspondantes, lorsqu'une entrée pertinente de la liste de blocage est trouvée. Le blocage physique d'une application ou d'une autorisation qui s'ensuit est documenté par une preuve de blocage authentique, qui est en outre envoyée par message du terminal aux instances responsables.

Les objets de verrouillage dans le contexte de l'AC sont les applications, les autorisations, les organisations et les clés (symétriques/asymétriques). La gestion des objets de verrouillage incombe à l'instance qui donne l'ordre. Ils sont représentés dans les listes de blocage par une entrée contenant au moins leur ID.

Les applications et les autorisations peuvent être bloquées et ne peuvent alors plus être utilisées dans le cadre de l'application principale. Le blocage a lieu en raison d'un changement de statut de l'application ou de l'autorisation sur le support de l'utilisateur Dans le cadre d'une authentification mutuelle entre les participants à la communication, il est possible de convenir d'une clé commune (la clé de démarrage) qui sera utilisée pour une communication sécurisée entre les deux partenaires. D'autres clés (clés de session) peuvent en être dérivées par dynamisation. Une clé (clé de session) utilisée dans un contexte de chiffrement ou de calcul MAC ou de contrôle peut être dérivée des clés de base par dérivation et dynamisation.

Le terme d'autorisation statique se réfère ici à un titre de transport électronique muni d'une signature numérique, qui peut être émis sous forme de jeu de données non modifiable sur différents supports, même simples. Il peut s'agir par exemple de

- d'un code-barres 2D imprimé sur papier ou enregistré sur un terminal mobile ou

- d'un jeu de données stocké sur une puce mémoire ou un téléphone portable NFC peu coûteux et lisible via une interface ISO 14443

La même clé (secrète) est utilisée par les deux partenaires de communication, tant pour le cryptage que pour le décryptage. Dans KA 1.X, les clés symétriques sont utilisées aussi bien pour l'authentification mutuelle des composants (les clés proviennent du Scheme Manager) que pour les preuves authentiques des dépenses d'autorisation ou des opérations de paiement (les clés proviennent du responsable du produit et du partenaire contractuel du client).

Afin de pouvoir réagir rapidement en cas de compromission de la clé et de pouvoir ainsi travailler avec une nouvelle clé, KA 1.X travaille avec une version régulière et une version de secours des clés. Dans (((etiCORE, toutes les clés symétriques des responsables de produits et des partenaires contractuels clients sont supprimées. Seules les clés symétriques pour l'authentification mutuelle des composants restent utilisées.

Au lieu de versions régulières et de secours, on utilise alors un registre de clés avec différentes générations de clés. Ces générations de clés sont déjà appliquées de manière fixe sur les composants. Si une clé d'authentification est trouvée sur une liste de blocage, le terminal négocie avec le SAM et le User Medium quelle clé d'authentification doit être utilisée.

Un tarif au sens du transport public est un contrat ou un élément contractuel comportant une énumération de conditions fixes pour la fourniture de prestations dans le cadre d'un contrat de transport. Les conditions contractuelles sont appelées tarif lorsqu'elles sont proposées unilatéralement par un fournisseur à de nombreux partenaires contractuels potentiels (clients) de manière uniforme.

Un produit tarifaire représente une offre de prestations standardisée pour l'utilisation des transports publics et se définit par les caractéristiques suivantes :

- le droit à la prestation au sens de la prestation pouvant être appelée (validité spatio-temporelle, etc.)

- le type de produit

- les conditions juridiques de transport (par ex. les droits tels que l'âge (enfant/adulte), le statut (par ex. écolier, retraité), etc.)

- ainsi que le prix du produit (tarif) pour le droit concret à la prestation.

Un produit tarifaire peut être étendu par l'octroi d'un ou de plusieurs avantages supplémentaires (interservices, intraservices) ou par l'intégration de prestations de service particulières (p. ex. remplacement en cas de perte) (voir également le contrat client).

Contrat de participation au (((eTicket-Allemagne). Le contrat de participation règle les droits et obligations spécifiques au (((eTicket)) des participants au (((eTicket)) Allemagne dans leurs différents rôles entre eux (responsable du produit, partenaire contractuel du client et prestataire de services) et vis-à-vis du Scheme Manager (VDV ETS).

Un billet est l'expression associée à un produit tarifaire d'une autorisation de voyager au sens du transport public de personnes (TPP) conformément aux dispositions tarifaires en vigueur. Chaque billet reflète un contrat de transport conclu. On distingue les billets valables immédiatement et les billets qui doivent être validés ou qui couvrent une période de validité définie plus longue (billets à durée déterminée). Les tickets sont entièrement stockés sur le support de l'utilisateur en tant que billet électronique.

Les systèmes IN-OUT constituent un cas particulier. Dans ce cas, il doit exister un produit tarifaire spécial dont le client a préalablement accepté les conditions d'utilisation. Au cours du voyage, les informations correspondantes sont générées sur le support d'information par l'enregistrement et la sauvegarde, et autorisent le client à effectuer le trajet correspondant. Les billets sont qualifiés de produit EFM par un responsable de produit et émis comme autorisation au client ou à l'utilisateur.

Titre de transport électronique avec des éléments de données TLV définis dans une annexe de KA BOM-Spec dans la structure de données Partie statique spécifique au produit et Transaction Partie spécifique au produit, qui peuvent être utilisés de manière variable pour décrire les paramètres tarifaires. Dans la version 1.x de KA, la transaction Partie spécifique au produit n'est pas utilisée pour le TVL-EFS.

En informatique, une transaction est une suite d'étapes de programme qui sont considérées comme une unité logique, car elles laissent la base de données dans un état cohérent après une exécution complète et sans erreur. C'est pourquoi on exige notamment d'une transaction qu'elle soit exécutée intégralement et sans erreur ou qu'elle ne soit pas exécutée du tout.

Dans le cadre de KA/(((etiCORE, les transactions au sens de cette définition ont lieu exclusivement entre le support de l'utilisateur (notamment la carte à puce) et le terminal d'acceptation.

Le compteur de temps de retard est une indication en minutes qui représente un retard du moyen de transport et qui corrige en conséquence une limitation de tickets individuels soumis à une limitation de temps.

Le compteur de temps de retard est également important pour les systèmes IN-OUT, lorsque, lors d'un nouvel enregistrement (enregistrement après la poursuite du trajet) dans un autre moyen de transport, celui-ci présente un retard correspondant. En tenant compte d'un compteur de temps de retard, le nouvel enregistrement peut être considéré comme une poursuite du voyage.

Terme générique désignant tous les types d'équipements de distribution périphériques, personnels ou automatiques, destinés à la vente de titres de transport électroniques et au chargement de montants débités sous forme d'unités de valeur sur le support de l'utilisateur ou sur un compte prépayé.

s. Unité de valeur du transport public / PT Value Units

L'autorisation d'unités de valeur (WEB) est la possibilité ou l'autorisation d'utiliser des unités de valeur affectées à des prestations de transport public sur le support utilisateur du transport public. L'autorisation d'unités de valeur représente d'une part une autorisation de circulation automatisée dans laquelle une mémoire d'unités de valeur est intégrée. Elle présente l'avantage de limiter l'accès à un objet dans le support de l'utilisateur lors de la détermination automatisée du prix du trajet on-trip dans le terminal et de combiner la transaction pour la comptabilisation des unités de valeur avec la transaction de saisie (transaction de trajet).

D'autre part, elle représente également, en dehors de son utilisation dans les systèmes IN-OUT, une (((autorisation de paiement électronique pour les prestations de transport public. En fonction du contrat client, il existe les deux possibilités d'utilisation suivantes :

- WE-preload

Cette expression définit une procédure sans dépassement accepté du WEB. Un solde négatif n'est pas possible. Elle doit présenter un solde minimum positif défini avant l'utilisation du TP. En règle générale, une recharge d'UE pour TP doit être effectuée avant l'utilisation de la prestation de TP.

- WE-postload

Cette expression définit une procédure selon laquelle le solde du WEB peut devenir négatif (découvert accepté) en raison du débit de WE de TP avant ou après l'utilisation du service de TP. Dans le cadre de cette procédure, une limite inférieure maximale est définie pour le solde du PEB, limite qui, lorsqu'elle est atteinte, est rejetée par le système. En ajoutant le solde manquant, le WEB est automatiquement rééquilibré lors du prochain chargement.

Un WEB permet une participation anonyme aux transports publics, alors dans la variante WE-preload. Une fonction de chargement automatique est possible pour l'autorisation des unités de valeur. Mais la participation anonyme au TP n'est alors pas possible, car une relation contractuelle est nécessaire pour cela.

s. Autorisation des unités de valeur / Stored Value (Unit) Payment Method

Synonyme d'utilisation d'un support d'utilisateur dans des systèmes IN-OUT qui prennent en charge des opérations de lecture/écriture à des distances supérieures à 20 cm. Généralement dans le contexte BeIn-Be-Out, par exemple avec BlueTooth LE.

Centre de commutation appartenant au réseau d'interopérabilité (ION) qui transmet les messages d'un participant ION au destinataire de ce message sur la base de l'identifiant de l'organisation indiqué comme destinataire. Le participant ION peut être l'éditeur de l'application, le service de contrôle et de liste de blocage ou un partenaire contractuel client, un prestataire de services ou un responsable de produit. Ils peuvent être reliés à ce centre de commutation directement ou via des adaptateurs.

L'instance "Certification" du Scheme Manager est responsable de la prescription uniforme des procédures de certification nécessaires pour l'application de base, de la réalisation de la certification de tous les composants du système et de la délivrance de certificats pour les composants pertinents du système de gestion électronique des billets.

Certificat supplémentaire se référant au SAM, nécessaire à l'émission du code-barres VDV sur la base de l'autorisation statique. Il n'est pas livré dans le SAM commandé, mais doit être commandé en plus auprès du Trustcenter en même temps que le SAM.

A partir de (((etiCORE, le SAM n'a pas besoin de certificat supplémentaire pour l'émission de codes-barres VDV, mais utilise pour cette fonctionnalité le certificat de sa clé de signature.