La tarifa (prorrateada) cobrada en un sistema IN-OUT para el trayecto o segmento de trayecto en el momento del embarque, que puede cobrarse en los casos en que se realiza un cargo por adelantado en una memoria de unidades de valor de transporte público o se paga directamente utilizando un monedero electrónico.

Una ASP administradora es una persona registrada en el proveedor de servicios de seguridad (TSI) como contacto administrativo en el sistema KM y PKI de una organización. La ASP administradora es una especialización de la ASP usuaria, ya que tiene derechos administrativos adicionales, es decir, puede crear y bloquear ASP usuarias.

Por lo general, la aplicación de transporte público se activa en el soporte de usuario directamente cuando éste se entrega al cliente. Para ello, se activa el estado de la aplicación con ayuda de una transacción de salida, se introduce un periodo de validez y se inicializa el contador de cambios de estado. A continuación, el cliente puede utilizar la aplicación.

Limpieza de la base de datos de gestión de acciones; esto elimina las órdenes de acción que ya se han ejecutado para emitir, desbloquear o cancelar de la base de datos de listas de acciones del sistema de listas de acciones del propietario del producto, para las que el propietario del producto (PV) ha recibido una prueba de control o bloqueo, pero no la prueba esperada (prueba de emisión o prueba de desbloqueo). En este caso, también deberá informarse al socio contractual del cliente que encargó esta acción.

Una lista de acciones es una lista de acciones que deben llevarse a cabo en el terminal de aceptación en el siguiente contacto con un medio de usuario. La proporciona el sistema del propietario del producto, la recuperan los socios contractuales clientes ejecutores y, a continuación, se distribuye a sus terminales de aceptación.

La gestión de acciones es una unidad administrativa en los sistemas del cliente contratante encargado, el cliente contratante ejecutor y el propietario del producto. Las acciones son elementos específicos que deben ejecutarse, que normalmente deben proporcionarse en forma de lista de acciones y están sujetas a un ciclo de vida (por lo tanto, deben gestionarse).

El sistema del propietario del producto ofrece el servicio de lista de acciones. A través de este servicio, los sistemas de las partes contratantes ejecutoras descargan las listas de acciones y las distribuyen a sus terminales. Por otro lado, las partes contratantes clientes encargadas pueden solicitar acciones al propietario del producto, que las coloca en la lista de acciones del propietario del producto.

El conjunto de la tecnología del dispositivo (hardware y software) que permite el intercambio de datos con un medio de usuario (ISO/IEC 14443). Se trata de

• Dispositivos para la creación de billetes completos (en chip y/o papel)
• Dispositivos para crear y/o completar billetes
• Dispositivos para recuperar información e imprimir billetes y vales/recibos
• Dispositivos para cargar unidades de valor de transporte público
• Dispositivos móviles para comprobar y/o validar los billetes
• Dispositivos de activación y personalización de la aplicación

Se distingue entre el sistema de variantes con preselección manual para la compra de billetes y el sistema IN-OUT.

Una aplicación se compone de datos, comandos, procesos, estados, mecanismos, algoritmos y código de programa, por ejemplo, dentro de una tarjeta inteligente o un smartphone, con el fin de hacerla funcionar dentro de un sistema específico. Los mecanismos incluyen la integración en la arquitectura de seguridad del sistema global respectivo, así como los protocolos de transmisión de la tarjeta inteligente.

El editor de la aplicación (AH) es el titular del contrato de aplicación para el uso de la aplicación de transporte público. Autoriza la reventa de la aplicación por parte de un socio contractual del cliente a un cliente. Define las normas de la aplicación y concede a un propietario de producto, a un socio contractual del cliente y a un proveedor de servicios el derecho a participar en los sistemas EFM, les proporciona los identificadores necesarios y les concede el derecho a utilizar las claves del editor de la aplicación. Autoriza a los socios contractuales del cliente a publicar aplicaciones en el soporte de usuario. Además, es responsable de proporcionar información sobre el identificador de instancia de la aplicación (identifica un medio de usuario) en caso de consultas sobre medios de usuario defectuosos. El editor de aplicaciones implementa la gestión del ciclo de vida de todas las instancias de aplicación.

Identificador de la aplicación

Identificador de la aplicación ubicada en el soporte de usuario. Dado que en una tarjeta chip pueden existir varias aplicaciones, por ejemplo, el identificador se utiliza para seleccionar la aplicación correcta (en este caso, la aplicación de transporte público).

Herramienta ASM

La herramienta ASM (Application and Security Management Tool) es el sistema central de servicios y administración del (((eTicket Germany). Da soporte a las principales tareas del Gestor de Esquemas para la gestión de aplicaciones y seguridad en (((eTicket Alemania, tales como

- Portal de servicios para el registro en (((eTicket Alemania)

- Servicio de atención al cliente para empresas de transporte y fabricantes

- Administración de clientes, fabricantes y participantes en (((eTicket

Alemania

- Suministro de documentos KA

- Pedido de componentes de seguridad KA, tramitación y comprobación de pedidos

y parte de los procesos de supervisión de la seguridad

y representa el sistema de referencia KA del emisor de la solicitud (AHS)

Se puede acceder a la herramienta ASM a través de https://asmtool.eticket-deutschland.de/asm-toolextern.

Criptografía asimétrica / Asymmetric Cryptography

Los métodos criptográficos asimétricos utilizan pares de claves formados por una clave pública y una clave privada. La clave pública no es secreta; debe ser conocida por el mayor número posible de usuarios. Puede utilizarse para realizar operaciones públicas, como cifrar mensajes o verificar firmas digitales. Es importante que una clave pública pueda asignarse claramente a un usuario. Esto se garantiza con un certificado. La clave privada es necesaria para descifrar un texto cifrado o firmar un mensaje. A diferencia de los procedimientos simétricos, en los que varios usuarios comparten una clave simétrica, en los procedimientos asimétricos sólo un usuario tiene la clave privada (secreta). Esta circunstancia permite asignar claramente una firma a un usuario.

Socio contractual del cliente ejecutor

El socio contractual cliente ejecutor (aKVP) autoriza la ejecución de una acción con un soporte de usuario en uno de sus terminales. Para ello, debe estar conectado al servicio de listas de acciones y a la gestión de acciones del propietario del producto a través de listas de acciones. También puede ser el socio contractual del cliente que autoriza (bKVP).

Emisión de la solicitud

Puede haber varias entidades autorizadas por el emisor de la aplicación para crear la aplicación en un soporte de usuario de acuerdo con la especificación dada y/o para activarla para su uso. La aplicación también puede emitirse a través del departamento de ventas. Siempre tendrá lugar a través de un socio contractual del cliente. La aplicación en el soporte de usuario también se denomina aplicación de transporte público.

Autoload

Con autorización de unidades de valor: Recarga automática con una cantidad acordada de unidades de valor PT para un contrato de cliente existente en función del cumplimiento de criterios acordados contractualmente (por ejemplo, alcanzar o quedar por debajo de una cantidad mínima). Esto tiene lugar para las unidades de valor PT almacenadas en el soporte de usuario en cada terminal de aceptación que detecta que no se ha alcanzado el importe mínimo de recarga y admite la función de recarga automática. Todos los importes de recarga se transfieren al sistema de fondo del socio contractual del cliente.

Para las cuentas de prepago (((Autorización de pago electrónico: Para la denominada autorización de cuenta de prepago abonada a través de una cuenta de crédito del cliente, la recarga desde la cuenta del cliente se controla a través del sistema de fondo del socio contractual del cliente principal.

El socio contractual del cliente primario es responsable de facturar al cliente y lleva a cabo la liquidación financiera con la parte que realizó la recarga. No es posible especificar manualmente la cantidad de autorizaciones de transporte que deben recargarse.

Tras la recarga automática, se realiza un asiento de cargo correspondiente al valor de las opciones de autorización de transporte recargadas en la cuenta de facturación almacenada para el contrato de cliente.

Autorización de viaje automatizada / Derecho IN-OUT

La autorización de viaje automatizada (AFB) da derecho al cliente a utilizar los servicios de transporte público. Regula la forma en que el cliente paga por el uso del servicio. El requisito previo para la utilización de la AFB es la existencia de una (((autorización de pago electrónico en el soporte del usuario. La AFB es, por tanto, un tipo de uso de la (((autorización de pago electrónico. Al utilizar la autorización como parte del registro de los datos de embarque y desembarque en los sistemas IN-OUT, se crea una prueba de servicio.

Una característica de la AFB es que define el marco de utilización y el cálculo de la tasa de servicio. Las AFB se emiten como medio de pago basado en una cuenta con procedimientos de prepago (PEB) o pospago (POB) en el sistema de fondo o como medio de pago basado en el usuario (WEB, puede ser anónimo) en los sistemas KA.

Identificador de la aplicación ubicada en el soporte de usuario. Como en una tarjeta chip pueden existir varias aplicaciones, por ejemplo, el identificador se utiliza para seleccionar la aplicación correcta (en este caso, la de transporte público).

La herramienta ASM (Application and Security Management Tool) es el sistema central de servicio y administración de (((eTicket Alemania). Soporta las principales tareas del Scheme Manager para la gestión de aplicaciones y seguridad en (((eTicket Alemania, tales como

- Portal de servicios para el registro en (((eTicket Germany)

- Servicio de atención al cliente para empresas de transporte y fabricantes

- Administración de clientes, fabricantes y participantes en (((eTicket Germany

- Suministro de documentos KA

- Pedido de componentes de seguridad KA, tramitación y comprobación de pedidos

y parte de los procesos de supervisión de la seguridad

y representa el sistema de referencia KA del emisor de la aplicación (AHS). Se puede acceder a la herramienta ASM a través de https://asmtool.eticket-deutschland.de/

Los métodos criptográficos asimétricos utilizan pares de claves formados por una clave pública y una clave privada. La clave pública no es secreta; debe ser conocida por el mayor número posible de usuarios. Puede utilizarse para realizar operaciones públicas, como cifrar mensajes o verificar firmas digitales. Es importante que una clave pública pueda asignarse claramente a un usuario. Esto se garantiza con un certificado. La clave privada es necesaria para descifrar un texto cifrado o firmar un mensaje. A diferencia de los procedimientos simétricos, en los que varios usuarios comparten una clave simétrica, en los procedimientos asimétricos sólo un usuario tiene la clave privada (secreta). Esta circunstancia permite asignar claramente una firma a un usuario.

El socio contractual del cliente ejecutor (aKVP) autoriza la ejecución de una acción con un soporte de usuario en uno de sus terminales. Para ello, debe estar conectado al servicio de listas de acciones y a la gestión de acciones del propietario del producto a través de listas de acciones. También puede ser el socio contractual del cliente que autoriza (bKVP).

Puede haber varias entidades autorizadas por el editor de la aplicación para crear la aplicación en un soporte de usuario de acuerdo con la especificación dada y/o para activarla para su uso. La aplicación también puede emitirse a través del departamento de ventas. Siempre tendrá lugar a través de un socio contractual del cliente. La aplicación en el soporte de usuario también se denomina aplicación de transporte público.

Con autorización de unidades de valor: Recarga automática con una cantidad acordada de unidades de valor PT para un contrato de cliente existente en función del cumplimiento de criterios acordados contractualmente (por ejemplo, alcanzar o quedar por debajo de un importe mínimo). Esto tiene lugar para las unidades de valor PT almacenadas en el soporte de usuario en cada terminal de aceptación que detecta que no se ha alcanzado el importe mínimo de carga y admite la función de recarga automática. Todos los importes de recarga se transfieren al sistema de fondo del socio contractual del cliente.

Para las cuentas de prepago (((Autorización de pago electrónico: En el caso de la denominada autorización de cuenta de prepago abonada a través de una cuenta de crédito del cliente, la recarga desde la cuenta del cliente se controla a través del sistema de fondo del socio contractual principal del cliente.

El socio contractual del cliente primario es responsable de facturar al cliente y lleva a cabo la liquidación financiera con la parte que realizó la recarga. No es posible especificar manualmente la cantidad de autorizaciones de transporte que deben recargarse. Tras la recarga automática, se realiza un asiento de cargo correspondiente al valor de las opciones de autorización de transporte recargadas en la cuenta de facturación almacenada para el contrato de cliente.

La autorización de viaje automatizada (AFB) da derecho al cliente a utilizar los servicios de transporte público. Regula la forma en que el cliente paga por el uso del servicio. El requisito previo para el uso de la AFB es la existencia de una (((autorización de pago electrónico en el soporte del usuario. La AFB es, por tanto, un tipo de uso de la (((autorización de pago electrónico. Al utilizar la autorización como parte del registro de los datos de embarque y desembarque en los sistemas IN-OUT, se crea una prueba de servicio.

Una característica de la AFB es que define el marco de utilización y el cálculo de la tasa de servicio. Las AFB se emiten como medio de pago basado en una cuenta con procedimientos de prepago (PEB) o pospago (POB) en el sistema de fondo o como medio de pago basado en el usuario (WEB, puede ser anónimo) en los sistemas KA.

Una autorización se basa en datos almacenados en una aplicación que autoriza el uso de un servicio de transporte público. Entre otras cosas, una autorización consta de un identificador único y un periodo de validez. Estos datos almacenados en la aplicación pueden adoptar la forma de un billete electrónico o de una (((autorización de pago electrónico. Un billete electrónico representa una autorización en el sentido de una autorización de viaje.

La (((autorización de pago electrónico utiliza las mismas estructuras de datos en el soporte de usuario, pero aún no es una autorización de viaje, sino sólo la base y el requisito previo para su uso en sistemas IN-OUT (y puede utilizarse allí como autorización de viaje automatizada (AFB)). Sin embargo, la autorización real para el viaje actual sólo se crea mediante un proceso de facturación junto con esta (((autorización de pago electrónico utilizada entonces como AFB.

Si la autorización es un billete electrónico (EFS), contiene más información sobre tarifas (producto, validez geográfica, etc.). El EFS puede ser anónimo o personalizado. Anónima significa que la posesión de la EFS es suficiente y cualquiera puede utilizarla. Personalizada significa que la EFS sólo puede ser utilizada por una persona concreta. En el caso de las EFS personalizadas, se utilizan medios de identificación adicionales durante el control.

Si se trata de una (((autorización de pago electrónico, el tipo determina si se basa en una cuenta (con opción de prepago o pospago) o si se utiliza junto con unidades de valor en el soporte de usuario. En las (((autorizaciones de pago electrónico, se distingue entre anónimas y no anónimas. Las autorizaciones anónimas (((ePayment) sólo son posibles en la variante de unidades de valor en el soporte de usuario sin la función autoload (que requiere una cuenta).

Las autorizaciones basadas en cuenta (((Las autorizaciones de ePayment nunca son anónimas, ya que la identidad del cliente se conoce en el sistema de fondo.

El socio contractual del cliente encargado (bKVP) inicia una acción (para una interacción posterior con un medio de usuario) para su cliente enviando una orden de acción al servicio de lista de acciones del propietario del producto.

En el sector del transporte, el contrato de transporte es un contrato para el transporte de pasajeros (más equipaje, si procede). En el transporte público, casi siempre se utiliza el contrato de transporte de pasajeros. La forma en que, es decir, con qué medios de pago, se liquida con el cliente la reclamación por la prestación del servicio de transporte.

Una autoridad de certificación (AC) es una organización que emite certificados digitales. Un certificado digital se utiliza para asignar una clave pública específica a una persona u organización (titular del certificado). Esta asignación es autenticada por la autoridad de certificación mediante su propia firma digital.

La autoridad de certificación es responsable de proporcionar, asignar y garantizar la integridad de los certificados que emite. De este modo, la CA actúa como tercero de confianza frente al titular del certificado y la parte que confía en la autenticidad del certificado. La CA constituye el núcleo de una infraestructura de clave pública.

La facturación después de la continuación del viaje es la ejecución de una nueva facturación después de una facturación ya completada como resultado de un cambio. El terminal determina la facturación tras la continuación del viaje de acuerdo con las especificaciones del propietario del producto en cuyo cálculo de tarifas se basa el viaje/cadena de viajes, por ejemplo, reconociendo el lugar de facturación = lugar de facturación (anterior) + criterio de tiempo en el que se acepta un cambio).

Véase también sistema IN-OUT.

Los mecanismos que regulan el envío y la recepción de datos entre el terminal y la tarjeta inteligente en el mundo de las tarjetas inteligentes. Describen detalladamente las capas de protocolo OSI utilizadas, el intercambio de datos en buenos casos, los mecanismos de detección de errores y los mecanismos de reacción en caso de error.

La compensación (de créditos) crea las condiciones previas para la realización de la remuneración del servicio entre las instancias participantes. La compensación puede compilar los datos de facturación de un usuario individual sobre la base de los datos de servicio comprimidos proporcionados, lo que en última instancia permite liquidar las reclamaciones.

1. recogida y clasificación de datos.

2. envío de datos (red)

3. verificación de los datos (aclaración)

(véase Operador de servicios PT)

Los productos EFM son definidos por el propietario del producto y cada uno de ellos puede representar uno o más productos tarifarios para su uso en la gestión electrónica de tarifas. Deben tener un número único para el propietario del producto y ser únicos en todo el sistema EFM junto con la identificación organizativa del propietario del producto.

Un producto EFM se define en términos de sus

- normas de uso

- Fijación de precios

Como modelo de producto, el producto EFM también define cómo deben almacenarse los parámetros del producto en el soporte del usuario en forma de los elementos de datos especificados. También define cómo

- estos parámetros deben utilizarse para calcular el precio

- se realiza un control automático a partir de los datos de la autorización

- los datos deben utilizarse para el control y el cálculo automático del precio en los sistemas IN-OUT

El billete electrónico describe un billete completo almacenado en un soporte de cliente, que (tras la validación necesaria) puede ser utilizado de esta forma por un pasajero directamente para un viaje en transporte público, por lo que la validez espacial y temporal se fija al inicio del uso y no puede modificarse posteriormente.

Un proceso elemental es un conjunto técnicamente coherente de transacciones, acciones, mensajes y comprobaciones que puede distribuirse entre distintos sistemas y asignarse a casos de uso individuales. Por lo tanto, un proceso elemental suele contener varios casos de uso.

Las solicitudes y autorizaciones pueden desbloquearse y reutilizarse dentro de (((eTicket Alemania. El desbloqueo tiene lugar cuando el estado de la aplicación o autorización en el soporte de usuario cambia de nuevo a "activo". De este modo, la solicitud o autorización vuelve a ser utilizable.

El desbloqueo sólo es posible en terminales autorizados del socio contractual del cliente.

Si el indicador de bloqueo se elimina de nuevo con la ayuda de un desbloqueo en una solicitud, se envía una prueba de desbloqueo al sistema de fondo del socio contractual del cliente. Si el indicador de bloqueo se elimina de nuevo con la ayuda de un desbloqueo en una autorización, se envía un certificado de desbloqueo al sistema de fondo del socio contractual del cliente y también al propietario del producto.

En el contexto del transporte público, por anulación se entiende la utilización de un billete que estaba previsto para un solo uso en cualquier momento correspondiente a la tarifa producto del billete. El uso del billete se certifica mediante un sello (billete de papel) o una prueba electrónica en un billete electrónico, que a su vez anula el billete ya que no puede volver a utilizarse. Por otra parte, mediante este proceso el billete sólo adquiere validez para el trayecto en curso.

Por registro se entiende la grabación de los procesos de entrada y salida (por ejemplo, entrada y salida) en los sistemas IN-OUT y su recogida y envío al propietario del producto. La prueba de ello se almacena en el soporte del usuario. En este contexto, se trata siempre del registro técnico de datos para el cálculo de los servicios, no, por ejemplo, del registro estadístico del número de pasajeros o similares. El responsable del registro de los datos es el proveedor de servicios de transporte público. Esto se debe a que debe poder aportar pruebas del servicio que presta y llevar a cabo un registro con este fin. Por lo tanto, el proveedor de servicios de transporte público cumple parte de la función de recogida y envío de conformidad con la norma ISO 24014 y es responsable del registro del servicio y de los datos de ingresos procedentes del uso de autorizaciones al utilizar los servicios de transporte de las empresas de transporte público.

Nota: Los procesos de control también pueden entenderse como recaudación, pero son un caso de uso aparte, véase Control.

Datos generados por los terminales de registro y transmitidos al sistema de fondo.

Término colectivo para todos los tipos de dispositivos periféricos para registrar el uso de los servicios de transporte en los vehículos y en las paradas en los sistemas IN-OUT. Pertenecen al grupo de terminales de aceptación.

Si el cliente no puede presentar un billete válido, deberá abonar un recargo por transporte (EBE).

s. Autorización / Derecho

Momento de la determinación (automática) basada en tarifas del valor del servicio de transporte público (determinación del precio) y del cobro del valor según el método de pago almacenado (momento del pago). Los procesos de determinación del precio y de pago están desacoplados, aunque el pago se efectúe inmediatamente después, sobre todo en el caso de la determinación previa del precio. En función de la tarifa, sólo son posibles determinados métodos de pago.

Existen las siguientes variantes de cálculo de tarifas:

- pretarifa: La tarifa se determina antes del viaje o trayecto. Esto significa normalmente que el billete se compra antes de que comience el viaje. Los métodos de pago válidos son

o cargo en una (((autorización de pago electrónico

o pago inmediato en efectivo

o débito a una tarjeta de crédito, tarjeta de débito, tarjeta de efectivo, etc.

- con precio de viaje: la tarifa se determina directamente al final del viaje (normalmente cuando se realiza el pago). Los métodos de pago válidos dentro de la aplicación principal son

o Débito en una autorización de unidad de valor (WEB)

- post-tarifa: La tarifa se fija un cierto tiempo después del viaje, normalmente en un sistema en segundo plano. Esto significa que el pago de un servicio de transporte público no se efectúa hasta un cierto tiempo después de que se haya utilizado el servicio. Sólo el procedimiento posttarifa permite al cliente obtener el mejor precio. Los métodos de pago válidos en

métodos de pago válidos son

o Cargo en cuenta

o Cuenta de pospago o cuenta de prepago del socio contractual del cliente

Nota: El momento del pago no tiene nada que ver con la forma de pago del cliente a través de su (((autorización de pago electrónico (en este caso también se utilizan los términos prepago y pospago). Como puede verse con el procedimiento de pospago, el pago posterior puede realizarse a través de una cuenta de prepago y la correspondiente (((autorización de pago electrónico) de prepago.

Un viaje es la utilización de un medio de transporte desde el embarque hasta el desembarque.

Un tramo de viaje es una parte de un viaje. Se puede caracterizar nombrando dos paradas.

El contador de uso incorrecto se incrementa cuando se introduce un PIN incorrecto. Por regla general, el PIN puede introducirse incorrectamente tres veces, tras lo cual el objeto protegido por PIN (normalmente una tarjeta chip en este caso) se bloquea y debe desbloquearse de nuevo mediante un PUK. Si el PIN se introduce correctamente, el contador de operaciones incorrectas se pone a 0.

El cliente tercero contratante realiza transacciones con aplicaciones o autorizaciones de clientes principales contratantes para las que está autorizado por las condiciones de uso. Esto se aplica principalmente al uso de (((autorizaciones de pago electrónico emitidas por la parte contratante cliente principal y destinadas a ser utilizadas por la parte contratante cliente tercera para el uso de servicios de transporte público (por ejemplo, compra de un billete en el entorno de la parte contratante cliente tercera con una (((autorización de pago electrónico de la parte contratante cliente principal.

Véase también el modelo de rol en la Spec-Main (para la lista de materiales de KA 1.X Spec HD).

Un centro de servicios comunes (GSS) es un sistema de abonado en segundo plano que asume y procesa las tareas específicas de cada función de los abonados conectados en una ubicación central. Además, los mensajes preprocesados se reenvían allí a los sistemas de abonados KA a través de la red de interoperabilidad (función de conmutación).

Todos los sistemas informáticos de un sistema de gestión electrónica de tarifas que procesan y gestionan datos a partir de la jerarquía del terminal de aceptación.

La inicialización de la aplicación PT crea la estructura de datos definida para la aplicación en el chip y rellena los campos de datos con valores predefinidos. El estado de la aplicación recibe el valor inicial "inicializado". La aplicación aún no puede utilizarse en este estado. También debe ser activada. Véase Activación de la aplicación.

Tipo de terminal de aceptación en el sistema de gestión de tarifas de un operador del sistema, por el que se crea automáticamente una prueba de servicio (parcial) en la aplicación al inicio del viaje y se completa o complementa automáticamente durante el transcurso del mismo (normalmente al final del viaje). Los sistemas representativos son

- Sistemas de entrada/salida (CICO),

- Sistemas de entrada/salida (BIBO).

- Sistemas de entrada/salida (CIBO)

El registro de prestaciones (parcial) creado automáticamente al inicio del viaje se considera una prueba de autorización de conducción válida. En los sistemas BIBO, la prueba de servicio se completa escribiendo en el soporte del usuario la siguiente parada tras la salida del medio de transporte.

La interoperabilidad es una característica de un producto o sistema cuyas interfaces son plenamente conocidas, de modo que puede cooperar con otros productos o sistemas actuales o futuros sin ninguna restricción, ya sea de aplicación o de acceso.

La siguiente descripción se refiere a la definición de interoperabilidad dentro de (((eTicket Deutschland:

La garantía tanto de un viaje continuo como de viajes individuales selectivos para el pasajero utilizando el mismo medio de usuario con la misma aplicación en las redes (sistemas de gestión de tarifas) de todas las empresas de transporte integradas contractualmente. Más información sobre la interoperabilidad aquí.

En los sistemas interoperables, es necesario intercambiar una gran cantidad de datos entre los distintos socios de los diferentes sistemas individuales. Esta tarea la realiza la red de interoperabilidad. Libera a las unidades operativas (editor de aplicaciones, servicio de listas de control y revocación, propietario del producto, socio contractual del cliente y proveedor de servicios) de tener que informarse sobre los detalles de la transferencia de datos.

La red de interoperabilidad (ION) propiamente dicha hace referencia a toda la red necesaria, lógica y físicamente, para el envío de mensajes entre los sistemas de abonado de toda Alemania.

El titular de la tarjeta es la persona que tiene poder real de disposición sobre la tarjeta. Si se utiliza la tarjeta, el titular se convierte en usuario de la misma. El titular es el propietario de la tarjeta. No es necesariamente el titular de la tarjeta.

El término tipo de tarjeta se utiliza en KA para distinguir entre diferentes versiones técnicas de una tarjeta con chip (por ejemplo, tarjeta de crédito, tarjeta con emulación Mifare, etc.).

El nombre Kernapplikation (KA) se refiere a la norma de ámbito alemán para sistemas de gestión electrónica de billetes para distintos operadores de transporte público o de sistemas en sus versiones 1 y 2. El nuevo nombre (((etiCORE se refiere a la versión 3. Ambas normas abarcan la seguridad, la certificación, el concepto organizativo y las interfaces de sistema pertinentes en el billetaje electrónico, que permite el uso interoperable de una aplicación de transporte público en un soporte de usuario.

Se define

- la realización de la especificación en un chip en un soporte de usuario y su interfaz con los terminales de aceptación necesarios

- la descripción de las interfaces necesarias entre los terminales de aceptación y los sistemas de fondo

- la descripción de las interfaces necesarias entre los sistemas de fondo de los distintos sistemas de gestión de tarifas y las instancias pertinentes

- la prueba de la conformidad y la seguridad de la norma mediante un procedimiento de certificación

La gestión de claves se refiere a todo el manejo de claves criptográficas, es decir, la generación, distribución, administración, almacenamiento, sustitución y supervisión de claves criptográficas (véase también criptografía de clave simétrica/asimétrica).

En Alemania, estas tareas están garantizadas por el Gestor de Esquemas (que sólo cubre un aspecto) y son realizadas por una instancia central, la subfunción del Gestor de Seguridad. En (((etiCORE, se omite la gestión de claves para las claves simétricas en los sistemas asociados del propietario del producto y del socio contractual del cliente.

El control verifica que el cliente/usuario cumple todos los requisitos necesarios para la utilización de un servicio de transporte público:

- soporte de cliente legible,

- solicitud válida (incluida la comprobación de la lista de bloqueo de solicitudes)

- autorización válida (incluida la comprobación de la lista de bloqueo de autorizaciones)

- producto válido (validez de la tarifa)

En primer lugar, interesa al prestador de servicios de transporte público, que factura sus servicios sobre la base de la prueba de la prestación. Si una de estas condiciones no se cumple, el control inicia el aumento de la tasa de transporte. El control también inicia el bloqueo de una solicitud o autorización en el soporte del cliente si se encuentran las entradas de bloqueo correspondientes en la lista de bloqueo. A partir de 2GSI / (((etiCORE, el bloqueo en el medio de usuario puede realizarse sin SAM.

En 1GSI / KA 1.X, se escribe una prueba de control en el medio de usuario además de enviarse al propietario del producto; a partir de 2GSI / (((etiCORE, la prueba de control sólo se envía al propietario del producto. Esto significa que a partir de 2GSI / (((etiCORE, la inspección es posible sin SAM. En términos de ISO 24014, la comprobación puede entenderse como parte del registro, pero es un caso de uso independiente.

El servicio de listas de control y revocación (KOSE) proporciona listas con entradas de revocación para

- autorizaciones

- aplicaciones

- módulos de aplicaciones seguras (SAM)

- claves

- organizaciones

Las entradas en las listas dedicadas indican que la instancia referenciada es robada, comprometida, inválida, etc. Para todas estas instancias, se pueden ejecutar nuevos comandos para añadir una entrada a estas listas o para eliminar una entrada de las mismas:

- por el Gestor del Esquema en relación con organizaciones, SAM y claves (en (((etiCORE sólo claves de autenticación))

- por los socios contractuales de los clientes en relación con las solicitudes y autorizaciones

Además, como parte de la recopilación y envío (véase ISO 24014-1), las credenciales de revocación (relativas a una autorización o a una aplicación) se procesan mediante su recopilación por parte de los proveedores de servicios y se ponen a disposición de los propietarios del producto (autorizaciones) y del emisor de la aplicación (aplicaciones). Véase el modelo de función en la especificación principal.

Soporte de la aplicación. Véase también soporte de usuario.

Datos del cliente es el término genérico para las preferencias del cliente y el perfil del cliente.

Datos individuales y seleccionables del cliente que se almacenan en la aplicación en el soporte del cliente y pueden utilizarse, por ejemplo, para agilizar el registro. No son automáticamente relevantes para el contrato. Son características preferentes del billete.

Todos los datos maestros personales que describen al cliente y que se almacenan en la aplicación en el soporte del cliente. Debido a su estructura de datos especificada, el perfil del cliente puede interpretarse de la misma manera en todas las interacciones con la aplicación. Sin embargo, puede utilizarse de forma específica para cada operador.

El servicio de atención al cliente se define en la norma ISO 24014-1 y realiza una amplia gestión de la información y las reclamaciones de cada cliente en relación con la aplicación principal VDV, incluidos los soportes de usuario robados o dañados. Esto incluye funciones de centro de llamadas, servicio de Internet y puede tener lugar a través de puntos de servicio regionales.

Un contrato de cliente en el sentido de (((eTicket Alemania representa una relación entre la empresa de transporte que presta un servicio al cliente y el cliente. El contrato de cliente describe las condiciones en las que el cliente puede utilizar los servicios ofrecidos por el transportista. Al mismo tiempo, se concede al cliente el derecho a utilizar un servicio. El contrato de cliente regula el cálculo de las tarifas y la facturación entre un socio contractual y un cliente. El contrato de cliente define principalmente los parámetros tarifarios que se aplicarán al usuario.

El contrato de cliente siempre está calificado por la identificación de la organización del socio contractual del cliente. El contrato de cliente se almacena en formato electrónico como una autorización (como (((autorización de pago electrónico o billete electrónico) sobre la base de un producto EFM definido por el propietario del producto en la aplicación de transporte público.

La función de socio contractual del cliente es una función especial en la aplicación principal. Consta de varios roles definidos en la norma ISO 24014-1:

- Minorista de productos

- Minorista de aplicaciones

- Servicio de atención al cliente

- Proveedor de identidades

- Proveedor de cuentas

- Proveedor de pagos

El socio contractual del cliente regula los procesos de venta del cliente, teniendo en cuenta las dependencias contractuales con el gestor del plan y el gestor del producto de los distintos servicios de movilidad. En particular, el socio contractual del cliente es responsable de la contabilidad, la emisión de billetes y la facturación de los distintos servicios de movilidad al cliente.

Por tanto, asume el papel de minorista de productos, minorista de aplicaciones (emisor de instancias) y proveedor de cuentas. Como proveedor de cuentas, utiliza los servicios de los proveedores de pago de su elección con los que mantiene una relación contractual. El socio contractual cliente puede actuar como socio contractual cliente principal o como socio contractual cliente tercero. Véase modelo de rol en Spec Main.

La unidad de personalización del socio contractual del cliente encapsula la comunicación entre el soporte usuario y el SAM. Consta, por tanto, de al menos un dispositivo de lectura/escritura con SAM.

Si un soporte de usuario debe imprimirse en forma de tarjeta chip, la impresora correspondiente también forma parte del CIP-PE. Por ejemplo, una máquina de confección de cartas en una personalizadora de masas es, en última instancia, también un CIP PE.

La unidad de ventas del socio contractual del cliente (KVP-VE) proporciona el software para la selección de aplicaciones de personalización, autorizaciones y comunicación con el sistema de fondo de referencia y proporciona los componentes de entrada y salida necesarios (monitor/teclado).

La prueba de servicio representa los datos de servicio almacenados en el soporte de usuario con fines de control, que describen la utilización del servicio por parte del cliente en el sistema IN-OUT.

Primer nivel de seguridad en la arquitectura de seguridad de la aplicación central del VDV (en (((eTicket Alemania). En el nivel 1, se utiliza un número muy limitado de ID de organización, que se utilizan como ejemplo para todos los participantes en sus funciones para la certificación de los componentes del sistema. Estas identificaciones especiales de organizaciones están diseñadas de tal forma que no son reconocidas por ningún sistema eficaz. Para las primeras pruebas en el desarrollo de componentes de sistemas, se recomienda trabajar en este nivel-1.

Segundo nivel de seguridad en la arquitectura de seguridad de la aplicación central VDV (en (((eTicket Alemania). En el nivel 2, todos los componentes de seguridad de KA (claves simétricas / asimétricas, SAM y medio de usuario) se generan y utilizan con ID de organización, que se asignan como complemento a los ID de organización activos o de nivel 3 asignados a los participantes.

En la versión KA 1.X, el primer bit del identificador de organización de 2 bytes se sustituye a tal efecto. Como resultado, al ID de organización de nivel 3 se le añade un valor de 8000 hexadecimal o 32768 decimal. Por ejemplo, la organización 5600 decimal o 15E0 hexadecimal se convierte entonces en el ID de organización 95E0 hexadecimal o 38368 decimal en el nivel 2.

En (((etiCORE, el nivel ya no se controla a través del propio ID de organización (que no se establece en 2 bytes), sino a través del certificado utilizado. Esto significa que los ID de organización en el nivel 2 y el nivel 3 son los mismos, y sólo la gestión de la seguridad o la salida de los certificados controla cómo se puede utilizar el entorno actual del sistema.

Tercer nivel de seguridad (el más alto) en la arquitectura de seguridad de la aplicación central VDV en (((eTicket Deutschland. En el nivel 3, todos los componentes de seguridad KA (claves simétricas / asimétricas, SAM y medio de usuario) se generan y utilizan con los ID de organización de nivel 3, que los participantes utilizan en sus sistemas KA para la identificación única, autenticación, cifrado y seguridad de las transacciones.

Todos los componentes de seguridad para la protección de extremo a extremo de los intereses de los participantes están protegidos aquí y no pueden acceder a ellos terceros. El nivel 3 está reservado para el funcionamiento activo. En el funcionamiento activo de (((eTicket Deutschland, sólo se utilizan y reconocen objetos de valor (p. ej. (((autorizaciones de pago electrónico)) que hayan sido creados con identificadores de organización de nivel 3. Para las normas (((etiCORE) sólo pueden utilizarse certificados de nivel 3.

Una prueba registra de forma auténtica una transacción a nivel de medio de usuario. Puede tratarse de la emisión de una autorización, registro de entrada o salida, prueba de control, bloqueo, desbloqueo, cancelación, cobro de unidades de valor, etc.

Las versiones de emergencia se utilizan para limitar los fallos y los daños (financieros) en caso de que una clave se vea comprometida. En efecto, esto significa que las claves de emergencia se almacenan en la aplicación además de las claves respectivas cuando se personaliza la aplicación. Es posible cambiar a estas claves de emergencia durante el funcionamiento.

A partir de (((etiCORE, el término ya no se utiliza, ya que se utiliza un mecanismo diferente para el uso de una clave diferente tras un compromiso de la clave. Véase Clave simétrica.

El usuario está en posesión del soporte de usuario y es el viajero (pasajero) en el sentido de la norma ISO 24014-1. Utiliza el servicio de transporte público de un determinado producto tarifario. A diferencia del cliente, el usuario también puede participar de forma anónima en (((eTicket Germany.

s. Kundenmedium / Customer Medium.

El usuario de la aplicación puede modificar los parámetros de la tarifa en los terminales en comparación con un contrato de transporte válido para un trayecto al que se apliquen los parámetros modificados (por ejemplo, regulación del take-along o cambio de clase de servicio).

Los contadores de uso se utilizan para conceder a los clientes tarifas especiales basadas en los servicios de transporte que utilizan en el caso del cálculo automatizado de tarifas. Con el cálculo de tarifas a posteriori, también puede realizarse un escenario de mejor precio o bonificación sin contadores de uso.

Sin embargo, con el cálculo de tarifas con precio por viaje en combinación con el uso de una autorización de unidad de valor, el contador de uso es necesario para conceder tarifas especiales sobre los servicios de transporte utilizados (por ejemplo, cálculo de un billete de un día a partir del cuarto viaje sencillo).

s. Asymmetrische Kryptographie / Criptografía asimétrica

El prestador de servicios de transporte público ofrece servicios de transporte a un cliente que ha adquirido la correspondiente autorización para utilizar dichos servicios. El contrato de transporte se celebra entre el prestador de servicios de transporte público y un usuario/pasajero en el momento de subir al medio de transporte.

El prestador de servicios adquiere el derecho a participar en el sistema EFM del gestor del sistema, regulado en una relación contractual (((contrato de participación eTicket). El prestador de servicios de transporte público celebra contratos con los gestores de productos para la aceptación de los productos y para el pago de los servicios de transporte prestados, así como con los socios contractuales de los clientes para la liquidación de los créditos contraídos (a través de la compensación de créditos).

Véase también el modelo de rol en la Spec-Main (para KA 1.X Spec HD BOM).

Unidades de valor asignadas pagadas por el cliente que se utilizan para el uso sin efectivo de servicios de transporte. Las unidades de valor de transporte público se adquieren con medios de pago válidos y aceptados en puntos de transporte público autorizados, se almacenan en la aplicación de transporte público y se cargan sucesivamente en la memoria de las terminales de transporte público autorizadas en función de los servicios (de transporte) utilizados. Las unidades de valor de transporte público corresponden a una cuota multiviaje de transporte público.

El ID de organización identifica de forma unívoca a una organización en todo el ámbito de la aplicación principal. El ID de organización consiste en el número de organización, que se asigna mediante el registro del gestor del sistema (VDV ETS) a través de la herramienta ASM cuando se celebra un contrato (((eTicket). Las organizaciones a las que se asigna un ID son personas jurídicas, normalmente empresas de transporte y asociaciones. En casos excepcionales, también pueden ser unidades operativas claramente delimitadas de una gran empresa.

Un número de identificación personal (PIN) es un código de acceso numérico (o menos comúnmente: alfanumérico) utilizado para autenticar a un usuario que accede a un sistema.

Se utiliza específicamente como parte de la aplicación principal: Código secreto de cuatro cifras que puede utilizarse para leer los datos del cliente en el soporte del usuario. Estos datos del cliente sólo pueden ser leídos auténticamente por terminales autorizados o por el propio cliente mediante su PIN.

Personalización en el sentido de (((eTicket Germany significa añadir datos personales a la aplicación del medio del usuario. De este modo se crea un perfil del cliente y, en su caso, sus preferencias. Los procesos técnicos para ello se describen en la especificación del medio de usuario.

El término "personal" suele utilizarse en relación con las autorizaciones y significa que una autorización sólo es válida para una persona concreta y no es transferible.

La infraestructura de clave pública (PKI) se refiere a un sistema que puede emitir, distribuir y verificar certificados digitales. Los certificados emitidos en el marco de una PKI se utilizan para proteger las comunicaciones informáticas. La PKI se utiliza en el campo de la criptografía asimétrica.

Se refiere a una cuenta a través de la cual se cargan los servicios de transporte público utilizados por el cliente mediante la autorización de pago prepago (PEB). En el caso de la opción de recarga automática, se puede recargar una cantidad de dinero acordada en una cuenta de cliente de una entidad de crédito conocida por el socio contractual del cliente cuando se alcanza un valor umbral acordado contractualmente. Los servicios de transporte público utilizados a través de la autorización se recogen independientemente de los datos personales del cliente y se cobran puntualmente a través de esta cuenta. Para cada cuenta de prepago existe al menos un contrato de cliente.

Nota: La creación de un método de pago prepago anónimo (sin autocarga) sería posible en principio, pero actualmente no está previsto como parte de la aplicación principal.

La parte contratante principal emite una solicitud o autorización. Su ID de organización se introduce en la solicitud o autorización para permitir que la solicitud o autorización se asigne a la parte contratante del cliente principal que la emitió.

Se refiere a una cuenta a través de la cual los servicios de transporte público utilizados por el cliente se liquidan a través de la (((autorización de pago electrónico (POB) contra factura o a través de una cuenta de cliente de una entidad de crédito conocida por el socio contractual principal del cliente. Los servicios de transporte público utilizados a través de la autorización se cobran independientemente de los datos personales del cliente y se cargan a través de esta cuenta en el momento acordado contractualmente. Existe al menos un contrato de cliente para cada cuenta de pospago.

No es posible establecer un procedimiento de pago pospago de forma anónima.

El término producto se utiliza en la aplicación principal en el sentido de producto tarifario de transporte público o producto EFM.

La compensación de productos (PCL) es un sistema centralizado que forma un servidor de tarifas para toda Alemania y conoce y puede calcular todas las tarifas de los participantes conectados a través de módulos de tarifas según PKM. La compensación de productos determina las tarifas y precios correctos para la cadena de viajes del cliente.

El PCL utiliza los módulos tarifarios PKM para calcular las tarifas. Este estándar abierto para la asignación digital de datos tarifarios forma parte de la aplicación central del VDV y no sólo proporciona información sobre las consultas relacionadas con los productos, sino que también calcula el producto tarifario correcto para el viaje en función de los parámetros tarifarios especificados por el usuario.

Todos los gestores de productos que participan en (((eTicket Deutschland ponen a disposición del sistema su módulo de tarifas actual. De este modo se crea un punto central para todos los datos sobre tarifas en Alemania.

El propietario del producto desarrolla productos EFM a partir de sus tarifas de servicios de transporte en una o varias zonas geográficas en las que varios proveedores de servicios de transporte público ofrecen servicios de transporte. El contrato de participación regula las modalidades necesarias entre el propietario del producto, los socios contractuales clientes y los proveedores de servicios de transporte público. El propietario del producto adquiere del gestor del sistema el derecho, regulado en una relación contractual, a participar en los sistemas EFM y a registrar en ellos sus productos. Recibe del gestor del sistema los identificadores y la información necesarios para gestionar sus fichas, derechos y módulos de seguridad.

Como parte de la gestión de la seguridad, el propietario del producto autoriza a los socios contractuales del cliente a emitir autorizaciones. El propietario del producto autoriza a los socios contractuales del cliente a vender sus productos.

Véase también el modelo de rol en Spec Main (para la lista de materiales de KA 1.X Spec HD)

La autorización de referencia proporciona una estructura definida que puede utilizarse tanto como autorización de viaje automatizada como para un billete electrónico. Por un lado, representa una especificación recomendada para una autorización de viaje automatizada con estructuras específicas del producto firmemente definidas para un uso interoperable.

Por otro lado, la autorización de referencia para un billete electrónico es una propuesta con estructuras específicas de producto firmemente predefinidas que pueden ser utilizadas por los gestores de producto a la hora de implementar billetes electrónicos. Como alternativa, el TLV-EFS ofrece aquí una propuesta algo más flexible y optimizada para la memoria

El sistema de referencia es un sistema imaginario, el terminal de referencia un terminal imaginario que combina funcionalidades básicas definidas. Estas funcionalidades básicas pueden encontrarse en uso real en diversos sistemas o en los tipos de terminales asociados al sistema. Las funcionalidades realizadas en el sistema o terminal real se implementan allí de forma análoga a los casos de uso en las especificaciones del sistema (de (((etiCORE: KVP-Ref - Dienstleisterumgesetzt.

Una instancia dentro de la Infraestructura de Clave Pública a la que personas, máquinas o autoridades de certificación subordinadas pueden solicitar certificados. La RA comprueba la exactitud de los datos del certificado solicitado y aprueba la solicitud de certificado, que es firmada por la autoridad de certificación (CA).

La subfunción de Registro del Gestor del Sistema se encarga de generar, organizar y responsabilizarse de los identificadores necesarios en el sistema para su uso interoperable, así como de gestionar los contratos necesarios para su organización y funcionamiento.

La versión normal de una clave (simétrica) puede utilizarse siempre que la clave no se vea comprometida. A partir de (((etiCORE, el término ya no se utiliza, ya que se utiliza un mecanismo diferente para el uso de una clave diferente tras un compromiso de la clave. Véase Clave simétrica. Véase también versión de emergencia.

El Gestor de Esquemas es la instancia superior de (((eTicket Deutschland. Esta tarea la realiza VDV ETS. El Scheme Manager combina las funciones de emisor de aplicaciones, registro y gestor de seguridad de la norma ISO 24014-1.

Crea los regímenes y los supervisa. Existe una sola vez en el sistema y se identifica de forma única. Encontrará más información en el modelo de funciones de la especificación principal.

El registro de claves pertenece a una función especial de la aplicación en el soporte de usuario. Es necesario en relación con la emisión de autorizaciones (en este contexto, se utiliza el término equívoco de autorización múltiple*.

Las claves utilizadas ya pueden estar protegidas para el socio contractual cliente emisor y el propietario previsto del producto cuando se emite la aplicación. Estas claves dependen del ID de instancia de la solicitud, pero no de un ID de autorización individual. Si es necesario, se pueden introducir claves adicionales para otros socios contractuales o propietarios de productos.

Cuando se emite una autorización, se introducen en el registro de claves las referencias necesarias a las claves existentes; la correspondencia de claves entre el soporte de usuario y el terminal para emitir una autorización supone una aceleración considerable. La autorización emitida en una aplicación con registro de claves no difiere técnicamente de una autorización en una aplicación sin registro de claves.

A partir del (((etiCORE, el uso de un registro de claves en relaciin con la emisiin de autorizaciones de esta forma ya no es necesario debido a la mayor rapidez de los procesos criptogrrficos. Sin embargo, existe un nuevo registro de claves utilizado para la autenticación de forma similar, en el que se almacenan las referencias a las generaciones de claves de autenticación, véase también Clave simétrica.

*El término multiautorización sugiere que podrían estar implicadas varias autorizaciones, que pueden utilizarse para diferentes servicios. Sin embargo, este término sólo se refiere al hecho de que las claves pueden utilizarse para varias autorizaciones con el fin de ahorrar tiempo en los procesos criptográficos durante el acceso. La autorización múltiple en sí no difiere de la autorización normal.

El módulo de aplicación segura (SAM) se utiliza como módulo de seguridad para los socios contractuales del cliente o los proveedores de servicios y ejecuta las funciones relevantes para la seguridad de los terminales de venta y/o los terminales de control que se comunican directamente con los soportes de usuario. También puede utilizarse para comprobar las firmas de transacciones generadas con el medio de usuario en los sistemas de fondo.

El Secure Crypto Environment (SCE) es un componente lógico del dispositivo móvil del pasajero capaz de recibir (o generar) y utilizar claves criptográficas y vincularlas de forma inmutable al dispositivo móvil y a una aplicación de emisión de billetes.

El SCE debe ser resistente a la lectura y copia de las claves en otro dispositivo móvil y puede utilizar el backend para autenticar las claves. Técnicamente, puede implementarse, por ejemplo, como una biblioteca que se integra en una aplicación de venta de entradas y utiliza los recursos de seguridad del dispositivo móvil, como un almacén de claves basado en hardware.

La arquitectura de seguridad de la aplicación central comprende 3 niveles de seguridad diferentes para pruebas y funcionamiento en directo, que se refieren al uso de medios de usuario, SAM, claves simétricas y asimétricas y los certificados asociados. Los niveles de seguridad y los entornos de producción asociados en el proveedor de servicios de seguridad están completamente separados para evitar cualquier riesgo de seguridad. De acuerdo con los distintos niveles de seguridad, una empresa participante recibe dos identificadores de organización para la versión KA 1.X, uno para el nivel 2 y otro para el nivel 3. Para (((etiCORE, se utilizan los certificados correspondientes a los distintos niveles de seguridad.

La solicitud de bloqueo tiene por objeto que un tercero responsable coloque un objeto en la lista de bloqueos correspondiente. Dependiendo del objeto, intervienen diferentes partes:

- Solicitud dirigida al socio contractual del cliente responsable para que se incluya una autorización en la lista de revocación. Esto puede ser iniciado por otro socio contractual del cliente, proveedor de servicios de transporte público o gestor de producto.

- Solicitud de inclusión de una solicitud en la lista negra a la parte contratante responsable. Puede hacerlo otro socio contractual del cliente, un proveedor de servicios de transporte público o el editor de la aplicación.

- Solicitud a los emisores de aplicaciones para que incluyan un módulo de aplicación segura, una clave (de (((claves de autenticación sólo etiCORE)) o una organización en la lista de revocación correspondiente. Esto puede ser iniciado por otro cliente socio contractual, proveedor de servicios de transporte público o propietario del producto.

La solicitud de revocación tiene por objeto provocar la eliminación de un objeto de la lista de revocación correspondiente por parte de un tercero responsable. Dependiendo del objeto, intervienen diferentes partes:

- Solicitud dirigida al socio contractual del cliente responsable para eliminar una autorización de la lista de revocación. Puede iniciarla otro socio contractual del cliente, un proveedor de servicios de transporte público o un gestor de productos.

- Solicitud dirigida al socio contractual del cliente responsable para eliminar una solicitud de la lista de revocaciones. Puede ser iniciada por otro socio contractual del cliente, un proveedor de servicios de transporte público o el editor de la aplicación.

- Solicitud dirigida al emisor de la aplicación para que elimine un módulo de aplicación segura, una clave (que ya no pertenezca a (((etiCORE)) o una organización de la lista de revocación correspondiente. Esto puede ser iniciado por otro cliente socio contractual, proveedor de servicios de transporte público o propietario del producto.

La petición de bloqueo se utiliza para añadir un objeto a la lista de bloqueos correspondiente. Existen diferentes iniciadores en función del objeto que deba añadirse:

- El socio contractual cliente responsable emite la orden de añadir una autorización o una aplicación a la lista de revocación.

- El responsable del régimen ordena añadir un módulo de aplicación segura o una organización a la lista de revocación.

- El titular de la clave (socio contractual del cliente, propietario del producto o gestor del régimen) ordena la adición de una clave (de (((etiCORE sólo el gestor del régimen como titular de la clave) a la lista de revocación correspondiente.

La solicitud de liberación de bloqueo se utiliza para eliminar un objeto de la lista de bloqueos correspondiente. Existen diferentes iniciadores en función del objeto que deba eliminarse:

- El socio contractual cliente responsable emite la orden de eliminar una autorización o una aplicación de la lista de revocación.

- El administrador del sistema ordena la eliminación de un módulo de aplicación segura o de una organización de la lista de revocación.

- El titular de la clave (socio contractual del cliente, propietario del producto o gestor del esquema) ordena la eliminación de una clave (a partir de (((etiCORE, ya no es posible una orden de liberación de claves por parte del gestor del esquema) de la lista de revocación correspondiente.

El motivo del bloqueo indica por qué se ha impuesto o se va a imponer un bloqueo.

Una lista de revocación consiste en un conjunto de entradas de lista de revocación para un objeto específico (autorización, aplicación, SAM, clave, organización). Se utiliza (tras una distribución adecuada en los sistemas/terminales) para detectar el uso no autorizado de una aplicación o la autorización que debe bloquearse para el uso de servicios de tráfico.

Sobre la base de la lista de bloqueo y sus entradas de lista de bloqueo, se lleva a cabo un bloqueo físico (para autorizaciones y aplicaciones) o un bloqueo lógico o el rechazo de una autorización o aplicación (debido a entradas de bloqueo SAM, clave u organización).

Una entrada de la lista de revocación se crea añadiendo un objeto a revocar (solicitud, autorización, organización, SAM, clave) a la lista de revocación.

Se crea un certificado de revocación cotejando la aplicación y las autorizaciones con las listas de revocación correspondientes si se encuentra una entrada de lista de revocación relevante. El posterior bloqueo físico de una aplicación o autorización se documenta mediante un certificado de bloqueo auténtico, que el terminal también envía a las instancias responsables a través de un mensaje.

Los objetos de bloqueo en el contexto de la KA son las aplicaciones, las autorizaciones, las organizaciones y las claves (simétricas/asimétricas). La administración de los objetos de revocación es responsabilidad de la instancia autorizadora. Se representan en las listas de revocación mediante una entrada con al menos su ID.

Las aplicaciones y autorizaciones pueden bloquearse y dejar de utilizarse como parte de la aplicación principal. El bloqueo se basa en un cambio de estado de la aplicación o autorización en el soporte de usuario En relación con la autenticación mutua entre los participantes en la comunicación, puede acordarse una clave común (la clave de inicio), que se utiliza para la comunicación segura entre ambos interlocutores. A partir de ella pueden derivarse otras claves (claves de sesión) mediante dinamización. A partir de las claves básicas puede derivarse una clave (clave de sesión) mediante derivación y dinamización, que se utiliza en un contexto de cifrado o de cálculo o verificación MAC.

El término autorización estática se refiere aquí a un ticket electrónico equipado con una firma digital, que puede emitirse como un registro de datos inalterable en diversos soportes, incluso simples. Puede tratarse, por ejemplo, de

- un código de barras 2D impreso en papel o almacenado en un dispositivo móvil o

- un registro de datos almacenado en un chip de memoria de bajo coste o en un teléfono móvil NFC y legible a través de una interfaz ISO 14443

Ambos interlocutores utilizan la misma clave (secreta) para cifrar y descifrar. Las claves simétricas se utilizan en KA 1.X tanto para la autenticación mutua de los componentes (las claves proceden del gestor del esquema) como para la prueba auténtica de cuestiones de autorización o transacciones de pago (las claves proceden del propietario del producto y del socio contractual del cliente).

Para poder reaccionar rápidamente con el intercambio de claves en caso de que éstas se vean comprometidas y poder así trabajar con una nueva clave, KA 1.X trabaja con versiones regulares y de emergencia de las claves. En (((etiCORE, se omiten todas las claves simétricas de los propietarios de los productos y de los socios contractuales de los clientes. Sólo se siguen utilizando las claves simétricas para la autenticación mutua de los componentes.

En lugar de versiones normales y de emergencia, se utiliza un registro de claves con diferentes generaciones de claves. Estas generaciones de claves ya están vinculadas permanentemente a los componentes. Si una clave de autenticación se encuentra en una lista de revocación, el terminal negocia con el SAM y el medio de usuario qué clave de autenticación debe utilizarse.

Una tarifa en el sentido del transporte público es un contrato o un componente contractual con una lista de condiciones fijas para la prestación de servicios en el marco de un contrato de transporte. Las condiciones contractuales se denominan tarifa si un proveedor las ofrece unilateralmente a muchos posibles socios contractuales (clientes) de forma normalizada.

Un producto tarifario representa una oferta de servicio normalizada para el uso del transporte público y se define por las siguientes características

- el derecho al servicio en términos del servicio que puede solicitarse (validez temporal y espacial, etc.)

- el tipo de producto

- las condiciones legales de transporte (por ejemplo, criterios de admisibilidad como la edad (niño/adulto), la situación (por ejemplo, estudiante, pensionista), etc.)

- así como el precio del producto (tarifa) para el derecho específico a las prestaciones.

Un producto tarifario puede ampliarse mediante la concesión de una o varias prestaciones adicionales (Interservicios, Intraservicios) o la integración de servicios especiales (por ejemplo, sustitución en caso de pérdida) (véase también el contrato con el cliente).

Contrato de participación en (((eTicket Germany. El contrato de participación regula los (((derechos y obligaciones específicos de eTicket de los participantes en (((eTicket Germany en sus diferentes funciones entre sí (propietario del producto, socio contractual del cliente y proveedor de servicios) y frente al gestor del programa (VDV ETS).

Un billete es la forma de autorización de viaje asociada a un producto tarifario en el sentido del transporte público (ÖPV) de acuerdo con la normativa tarifaria aplicable. Cada billete refleja un contrato de transporte celebrado. Se distingue entre billetes de validez inmediata y billetes que deben ser validados o que cubren un periodo de validez definido más largo (abonos de temporada). Los billetes se almacenan íntegramente en el soporte del usuario como billetes electrónicos.

Los sistemas IN-OUT constituyen un caso especial. En este caso, debe existir un producto tarifario especial cuyas condiciones de uso hayan sido aceptadas previamente por el cliente. Durante el transcurso del viaje, la información asociada que autoriza al cliente a viajar se genera en el medio de usuario mediante la facturación y la salida y el almacenamiento. Los billetes son calificados como producto EFM por un gestor de producto y emitidos al cliente o usuario como autorización.

Billete electrónico con elementos de datos TVL definidos en un anexo de KA BOM-Spec en la estructura de datos Static Product-Specific Part y Transaction Product-Specific Part, que pueden utilizarse de forma variable para describir parámetros de tarifa. En la versión KA 1.x, la transacción Parte específica del producto no se utiliza para el TVL-EFS.

En informática, una transacción es una secuencia de pasos de programa que se consideran una unidad lógica porque dejan la base de datos en un estado coherente tras una ejecución completa y sin errores. Por lo tanto, una transacción debe ejecutarse completamente y sin errores o no ejecutarse en absoluto.

En el contexto de KA/(((etiCORE, las transacciones en el sentido de esta definición tienen lugar exclusivamente entre el soporte de usuario (en particular, la tarjeta chip) y la terminal de aceptación.

El contador de tiempo de retraso es una indicación en minutos que representa un retraso del medio de transporte y corrige en consecuencia una restricción de billetes individuales sujetos a un límite de tiempo.

El contador de tiempo de retraso también es importante para los sistemas IN-OUT si hay un retraso correspondiente al facturar de nuevo (facturar después de continuar el viaje) en otro medio de transporte. Si se tiene en cuenta un contador de retrasos, la nueva facturación puede contabilizarse como una continuación del viaje.

Término colectivo para todos los tipos de dispositivos de venta periféricos automáticos y operados por el personal para la venta de billetes electrónicos y para cargar importes de débito como unidades de valor en el soporte del usuario o en una cuenta de prepago.

s. Unidades de valor PT

La autorización de unidad de valor (WEB) es la opción o el permiso para utilizar unidades de valor asignadas para servicios de transporte público en el medio de transporte público del usuario. Por un lado, la autorización de unidad de valor representa una autorización de viaje automatizada en la que se integra una memoria de unidad de valor. Tiene la ventaja de que restringe el acceso a un objeto en el soporte de usuario durante el cálculo automatizado de la tarifa del viaje en el terminal y la transacción para la reserva de la unidad de valor se combina con la transacción de registro (transacción del viaje).

Por otro lado, también representa una (((autorización de pago electrónico para servicios de transporte público fuera de su uso en sistemas IN-OUT. Dependiendo del contrato con el cliente, existen las dos opciones de uso siguientes:

- WE-precarga

Esta expresión define un procedimiento sin descubierto aceptado de la WEB. No es posible un saldo negativo. Debe tener un saldo mínimo positivo definido antes de utilizar la APP. Por lo general, una precarga WE de transporte público debe realizarse antes de utilizar el servicio de transporte público.

- WE-postcarga

Este término define un procedimiento en el que el saldo de la WEB puede caer en negativo (descubierto aceptado) debido a la carga de la WE de transporte público antes o después de la utilización del servicio de transporte público. Este procedimiento define un límite inferior máximo para el saldo de la WEB, que es rechazado por el sistema cuando se alcanza. Al añadir el déficit, la WEB vuelve a equilibrarse automáticamente la próxima vez que se carga.

Una WEB permite la participación anónima en el transporte público, luego en la variante WE-precarga. Es posible una función de autocarga para la autorización de unidades de valor. Sin embargo, la participación anónima en el transporte público no es posible en este caso, ya que para ello se requiere una relación contractual.

s. Autorización de unidad de valor / Valor almacenado (Unidad) Forma de pago

Sinónimo del uso de un medio de usuario en sistemas IN-OUT que admiten operaciones de lectura/escritura a distancias superiores a 20 cm. Normalmente en el contexto BeIn-Be-Out, por ejemplo con BlueTooth LE.

Centro de conmutación perteneciente a la red de interoperabilidad (ION) que reenvía los mensajes de un abonado ION al destinatario de este mensaje en función del identificador de organización especificado como destinatario. El suscriptor ION puede ser el editor de la aplicación, el servicio de listas de control y revocación o un socio contractual del cliente, proveedor de servicios o propietario del producto. Estos pueden estar conectados a este centro de conmutación directamente o a través de un adaptador.

La instancia "Certificación" del administrador del sistema es responsable de la especificación normalizada de los procedimientos de certificación necesarios para la aplicación principal, de llevar a cabo la certificación de todos los componentes del sistema y de expedir certificados para los componentes pertinentes del sistema de gestión electrónica de tarifas.

Certificado adicional relacionado con SAM que se necesita para emitir el código de barras VDV basado en la autorización estática. No se suministra con la SAM solicitada, sino que debe solicitarse adicionalmente al Centro de Confianza junto con la SAM.

A partir de (((etiCORE, el SAM no requiere un certificado adicional para emitir códigos de barras VDV, sino que utiliza el certificado de su clave de firma para esta funcionalidad.