The (pro rata) fare charged in an IN-OUT system for the journey or journey segment at boarding, which can be charged in cases where a debit is made in advance from a public transport value unit memory or paid directly using an electronic wallet.

An admin ASP is a person who is registered with the security service provider (TSI) as the administrative contact in the KM and PKI system for an organisation. The admin ASP is a specialisation of the user ASP, as it has additional administrative rights, i.e. it can create and block user ASPs.

The public transport application is usually activated on the user medium directly when the user medium is issued to the customer. For this purpose, the status of the application is set to active with the help of an output transaction, a validity period is entered and the status change counter is initialised. The application can then be used by the customer.

Cleansing the action management database; this removes action orders that have already been executed for issuing, unblocking or cancelling from the action list database in the product owner's action list system, for which the product owner has received proof of control or blocking, but not the expected proof (proof of issue or proof of unblocking). In this case, the customer contract partner who commissioned this action must also be informed.

An action list is a list of actions to be carried out at the acceptance terminal at the next contact with a user medium. It is provided by the product owner's system, retrieved by the executing customer contract partners and then distributed to their acceptance terminals.

Action management is an administrative unit in the systems of the commissioning customer contract partner, executing customer contract partner and product owner. Actions are specific elements to be executed, which usually have to be provided in the form of an action list and are subject to a life cycle (therefore they have to be managed).

The action list service is offered by the product owner's system. Via this service, the systems of the executing customer contract partners download the action lists and distribute them to their terminals. On the other hand, commissioning customer contract partners can order actions from the product owner, which places them on the product owner's action list.

The entirety of device technology (hardware and software) that enables data exchange with a user medium (ISO/IEC 14443). These are

• Devices for the creation of complete tickets (on chip and/or paper)
• Devices for creating and/or completing tickets
• Devices for retrieving information and printing tickets and vouchers/receipts
• Devices for loading public transport value units
• Mobile devices for checking and/or validating tickets
• Devices for activating and personalising the application

A distinction is made between the system variants system with manual pre-selection for ticket purchase and IN-OUT system.

An application consists of data, commands, processes, states, mechanisms, algorithms and programme code, e.g. within a smart card or a smartphone, in order to operate it within a specific system. The mechanisms include the integration into the security architecture of the respective overall system as well as the chip card transmission protocols.

The application publisher (AH) holds the application contract for the use of the public transport application. It authorises the resale of the application by a customer contract partner to a customer. It defines the application rules and grants a product owner, a customer contract partner and a service provider the right to participate in the EFM systems, provides them with the necessary identifiers and grants the right to use the application publisher's keys. He authorises customer contract partners to issue applications in the user medium. In addition, it is responsible for providing information about the instance ID of the application (identifies a user medium) in the event of enquiries regarding defective user media. The application publisher implements lifecycle management for all application instances.

Application identifier

Identifier of the application located on the user medium. As several applications can exist on a chip card, for example, the identifier is used to select the correct application (in this case the public transport application).

ASM tool

The ASM Tool (Application and Security Management Tool) is the central service and administration system for the (((eTicket Germany. It supports the main tasks of the Scheme Manager for application and security management in (((eTicket Germany, such as

- Service portal for registration for the (((eTicket Germany

- Customer service for transport companies and manufacturers

- Administration of customers, manufacturers and participants in (((eTicket

Germany

- Provision of KA documents

- Ordering of KA security components, order processing and checking

and part of the security monitoring processes

and it represents the KA reference system of the application issuer (AHS)

The ASM tool can be accessed via https://asmtool.eticket-deutschland.de/asm-toolextern.

Asymmetric Cryptography / Asymmetric Cryptography

Asymmetric cryptographic methods use key pairs consisting of a public key and a private key. The public key is not secret; it should be known to as many other users as possible. It can be used to carry out public operations, i.e. encrypt messages or verify digital signatures. It is important that a public key can be clearly assigned to a user. This is guaranteed with a certificate. The private key is required to decrypt an encrypted text or sign a message. In contrast to symmetric procedures, where several users share a symmetric key, in asymmetric procedures only one user has the private (secret) key. This circumstance makes it possible to clearly assign a signature to a user.

Executing Customer Contract Partner

The executing customer contract partner (aKVP) authorises the execution of an action with a user medium at one of its terminals. To do so, he must be connected to the action list service and action management of the product owner via action lists. He can also be the Authorising Customer Contract Partner (bKVP).

Issuing the application

There may be several entities that are authorised by the application issuer to create the application on a user medium in accordance with the given specification and/or to activate it for use. The application can also be issued via the sales department. It will always take place via a customer contract partner. The application on the user medium is also referred to as a public transport application.

Autoload

With value unit authorisation: Automatic top-up with an agreed quantity of PT value units for an existing customer contract depending on the fulfilment of contractually agreed criteria (e.g. reaching or falling below a minimum amount). This takes place for PT value units stored in the user medium at each acceptance terminal that detects that the minimum charging amount has not been reached and supports the autoload function. All top-up amounts are transferred to the background system of the customer contract partner.

For prepaid accounts (((ePayment authorisation: For so-called prepaid account authorisation credited via a credit account of the customer, reloading from the customer's account is controlled via the background system of the primary customer contract partner.

The primary customer contract partner is responsible for invoicing the customer and carries out the financial settlement with the party that realised the top-up. It is not possible to manually specify the quantity of transport authorisation options to be topped up.

Following the autoload, a debit entry corresponding to the value of the travel authorisation options topped up is made to the billing account stored for the customer contract.

Automated driving authorisation / IN-OUT Entitlement

The automated travel authorisation (AFB) entitles the customer to use public transport services. It regulates how the customer pays for the use of the service. The prerequisite for the use of the AFB is the existence of an (((e-payment authorisation on the user medium. The AFB is therefore a type of use of the (((e-payment authorisation. In the course of using the authorisation as part of recording boarding and alighting data in IN-OUT systems, a proof of service is created.

A characteristic of the AFB is that it defines the framework for utilisation and the calculation of the service charge. AFBs are issued as an account-based payment method with prepaid (PEB) or postpaid (POB) procedures in the background system or as a user-medium-based payment method (WEB, can be anonymous) in KA systems.

Identifier of the application located on the user medium. As several applications can exist on a chip card, for example, the identifier is used to select the correct (in this case the public transport) application.

The ASM tool (Application and Security Management Tool) is the central service and administration system for (((eTicket Germany. It supports the main tasks of the Scheme Manager for application and security management in (((eTicket Germany, such as

- Service portal for registration for the (((eTicket Germany

- Customer service for transport companies and manufacturers

- Administration of customers, manufacturers and participants in (((eTicket Germany

- Provision of KA documents

- Ordering of KA security components, order processing and checking

and part of the security monitoring processes

and it represents the KA reference system of the application issuer (AHS). The ASM tool can be accessed via https://asmtool.eticket-deutschland.de/

Asymmetric cryptographic methods use key pairs consisting of a public key and a private key. The public key is not secret; it should be known to as many other users as possible. It can be used to carry out public operations, i.e. encrypt messages or verify digital signatures. It is important that a public key can be clearly assigned to a user. This is guaranteed with a certificate. The private key is required to decrypt an encrypted text or sign a message. In contrast to symmetric procedures, where several users share a symmetric key, in asymmetric procedures only one user has the private (secret) key. This circumstance makes it possible to clearly assign a signature to a user.

The executing customer contract partner (aKVP) authorises the execution of an action with a user medium at one of its terminals. To do so, he must be connected to the action list service and action management of the product owner via action lists. He can also be the Authorising Customer Contract Partner (bKVP).

There may be several entities that are authorised by the application publisher to create the application on a user medium in accordance with the given specification and/or to activate it for use. The application can also be issued via the sales department. It will always take place via a customer contract partner. The application on the user medium is also referred to as a public transport application.

With value unit authorisation: Automatic top-up with an agreed quantity of PT value units for an existing customer contract depending on the fulfilment of contractually agreed criteria (e.g. reaching or falling below a minimum amount). This takes place for PT value units stored in the user medium at each acceptance terminal that detects that the minimum charge amount has not been reached and supports the autoload function. All top-up amounts are transferred to the background system of the customer contract partner.

For prepaid accounts (((ePayment authorisation: For so-called prepaid account authorisation credited via a credit account of the customer, reloading from the customer's account is controlled via the background system of the primary customer contract partner.

The primary customer contract partner is responsible for invoicing the customer and carries out the financial settlement with the party that realised the top-up. It is not possible to manually specify the quantity of transport authorisation options to be topped up. Following the autoload, a debit entry corresponding to the value of the travel authorisation options topped up is made to the billing account stored for the customer contract.

The automated travel authorisation (AFB) entitles the customer to use public transport services. It regulates how the customer pays for the use of the service. The prerequisite for the use of the AFB is the existence of an (((e-payment authorisation on the user medium. The AFB is therefore a type of use of the (((e-payment authorisation. In the course of using the authorisation as part of recording boarding and alighting data in IN-OUT systems, a proof of service is created.

A characteristic of the AFB is that it defines the framework for utilisation and the calculation of the service charge. AFBs are issued as an account-based payment method with prepaid (PEB) or postpaid (POB) procedures in the background system or as a user-medium-based payment method (WEB, can be anonymous) in KA systems.

An authorisation is based on data stored in an application that authorises the use of a public transport service. Among other things, an authorisation consists of a unique ID and a validity period. This data stored in the application can be in the form of an electronic ticket or an (((e-payment authorisation. An electronic ticket represents an authorisation in the sense of a travel authorisation.

The (((e-payment authorisation uses the same data structures on the user medium, but is not yet a travel authorisation, but only the basis and prerequisite for use in IN-OUT systems (and can be used there as an automated travel authorisation (AFB)). However, the actual authorisation for the current journey is only created by a check-in process together with this (((e-payment authorisation then used as an AFB.

If the authorisation is an electronic ticket (EFS), it contains further tariff information (product, geographical validity, etc.). The EFS can be anonymous or personalised. Anonymous means that possession of the EFS is sufficient and anyone can use it. Personalised means that the EFS may only be used by a specific person. For a personalised EFS, additional means of identification are used during the check.

If it is an (((e-payment authorisation, the type determines whether it is account-based (with prepaid or postpaid option) or used in conjunction with value units on the user medium. With (((e-payment authorisation, there is a distinction between anonymous and non-anonymous. Anonymous (((ePayment authorisations are only possible in the variant of value units on the user medium without the autoload function (which requires an account).

Account-based (((ePayment authorisations are never anonymous, as the customer identity is known in the background system.

The commissioning customer contract partner (bKVP) initiates an action (for a subsequent interaction with a user medium) for its customer by sending an action order to the action list service of the product owner.

In the transport sector, the contract of carriage is a contract for the carriage of passengers (plus luggage, if applicable). In public transport, the passenger transport contract is almost always used. The way in which, i.e. with which means of payment, the claim for the provision of the transport service is settled with the customer.

A certification authority (CA) is an organisation that issues digital certificates. A digital certificate is used to assign a specific public key to a person or organisation (certificate holder). This assignment is authenticated by the certification authority by providing it with its own digital signature.

The certification authority is responsible for providing, assigning and ensuring the integrity of the certificates it issues. The CA thus acts as a trusted third party vis-à-vis the certificate holder and the party relying on the authenticity of the certificate. The CA forms the core of a public key infrastructure.

Check-In after continuation of journey is the execution of a new Check-In after an already completed Check-In Check-Out as a result of a change. The terminal determines the check-in after continuation of the journey according to the specifications of the product owner whose fare calculation the journey/journey chain is based on, e.g. by recognising check-in location = (previous) check-out location + time criterion in which a change is accepted).

See also IN-OUT system.

The mechanisms that regulate the sending and receiving of data between the terminal and smart card in the smart card world. They describe in detail the OSI protocol layers used, data exchange in good cases, error detection mechanisms and reaction mechanisms in the event of errors.

(Receivables) clearing creates the prerequisites for the realisation of service remuneration between the participating instances. Clearing can compile the billing data for an individual user on the basis of the compressed service data provided, which ultimately enables claims to be settled.

1. collection and sorting of data.

2. data forwarding (network)

3. verification of data (clarification)

(see PT Service Operator)

EFM products are defined by the product owner and can each represent one or more fare product(s) for use in electronic fare management. They must have a unique number for this product owner and be unique throughout the EFM system together with the product owner's organisational ID.

An EFM product is defined in terms of its

- usage rules

- Pricing

As a product template, the EFM product also defines how the parameters of the product are to be stored on the user medium in the form of the specified data elements. It also defines how

- these parameters must be used to calculate the price

- an automatic check is carried out using the data in the authorisation

- the data must be used for checking and automated price calculation in IN-OUT systems

The electronic ticket describes a fully-fledged ticket stored on a customer medium, which (after any necessary validation) can be used in this form by a passenger directly for a journey on public transport, whereby the spatial and temporal validity is fixed at the start of use and cannot be changed afterwards.

An elementary process refers to a technically coherent set of transaction(s), actions, messages and checks that can be distributed across different systems and assigned to individual use cases. An elementary process therefore usually contains several use cases.

Applications and authorisations can be unlocked and can then be reused within (((eTicket Germany. Unblocking takes place when the status of the application or authorisation on the user medium changes back to "active". This makes the application or authorisation usable again.

Unblocking is only possible at authorised terminals of the customer contract partner.

If the blocking flag is removed again with the help of an unblocking in an application, a proof of unblocking is sent to the background system of the customer contract partner. If the blocking flag is removed again with the help of an unblocking in an authorisation, an unblocking certificate is sent to the background system of the customer contract partner and also to the product owner.

Cancellation in the context of public transport means the use of a ticket that was intended for a single use at any time corresponding to the fare product of the ticket. The use of the ticket is certified by a stamp (paper ticket) or electronic proof in an electronic ticket, which in turn cancels the ticket as it cannot be used again. On the other hand, the ticket only becomes valid for the current journey through this process.

Recording means the recording of in-out processes (e.g. check-in and check-out) in IN-OUT systems and their collection and forwarding to the product owner. Proof of this is stored on the user medium. In this context, this always refers to the technical recording of data for the calculation of services, not, for example, the statistical recording of passenger numbers or similar. The public transport service provider is responsible for recording the data. This is because they must be able to provide evidence of the service they provide and carry out a recording for this purpose. The public transport service provider therefore fulfils part of the role of collection and forwarding in accordance with ISO 24014 and is responsible for the service recording and revenue data from the use of authorisations when using the transport services of public transport companies.

Note: Control processes can also be understood as collection, but are a separate use case, see Control.

Data generated by recording terminals and transmitted to the background system.

Collective term for all types of peripheral devices for recording the use of transport services in vehicles and at stops in IN-OUT systems. They belong to the group of acceptance terminals.

An increased transport charge (EBE) is due if a customer cannot present a valid ticket.

s. Authorisation / Entitlement

Time of the (automatic) tariff-based determination of the value of the public transport service (price determination) and the charging of the value according to the stored payment method (payment time). The processes for price determination and payment are decoupled, even if payment is made immediately afterwards, particularly in the case of pre-priced price determination. Depending on the tariff, only certain payment methods are possible.

The following fare calculation variants are available:

- pre-priced: The fare is determined before the journey or trip. This usually means that a ticket is purchased before the journey begins. Valid payment methods are:

o debit to a (((e-payment authorisation

o immediate payment by cash,

o debit to a credit card, debit card, cash card, etc.

- trip-priced: The fare is determined directly after the end of a journey (usually when the check-out is due). Valid payment methods within the core application are

o Debit on a value unit authorisation (WEB)

- post-priced: The fare is set a certain time after the journey, usually in a background system. This means that payment for a public transport service is only made some time after the service has been used. Only the post-priced procedure enables the customer to obtain the best price. Valid

payment methods are

o Debit to

o Postpaid account or prepaid account of the customer contract partner

Note: The time of payment has nothing to do with the customer's payment method using their (((e-payment authorisation (the terms prepaid and postpaid are also used there). As can be seen with the post-priced procedure, subsequent payment can be made via a prepaid account and the corresponding prepaid (((e-payment authorisation.

A journey is the use of a means of transport from boarding to alighting.

A journey section is a part of a journey. It can be characterised by naming two stops.

The incorrect use counter is incremented when an incorrect PIN is entered. As a rule, the PIN may be entered incorrectly three times, after which the PIN-protected object (usually a chip card in this case) is blocked and must be unblocked again using a PUK. If the PIN is entered correctly, the incorrect operation counter is reset to 0.

The third-party customer contract partner carries out transactions with applications or authorisations of primary customer contract partners for which it is authorised by the terms of use. This primarily applies to the use of (((e-payment authorisations issued by the primary customer contract partner and intended to be used by the third-party customer contract partner for the use of public transport services (e.g. purchase of a ticket in the environment of the third-party customer contract partner with an (((e-payment authorisation of the primary customer contract partner.

See also role model in the Spec-Main (for KA 1.X Spec HD BOM).

A Common Service Centre (CSC) is a background subscriber system that takes over and processes role-specific tasks of the connected subscribers at a central location. In addition, pre-processed messages are forwarded there to KA subscriber systems via the interoperability network (switching function).

All computer systems of an electronic fare management system that process and manage data from the acceptance terminal hierarchy onwards.

The initialisation of the PT application creates the data structure defined for the application on the chip and fills data fields with predefined values. The application status is given the initial value "initialised". The application cannot yet be used in this state. It must also be activated. See Activating the application.

A type of acceptance terminal in the fare management system of a system operator, whereby a (partial) proof of service is automatically created in the application at the start of the journey and automatically completed or supplemented during the course of the journey (usually at the end of the journey). System representatives are

- Check-in/check-out systems (CICO),

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

- Check-in/be-out systems (CIBO)

The (partial) performance record automatically created at the start of the journey is regarded as proof of valid driving authorisation. In BIBO systems, the proof of service is completed by writing the next stop after the departure of the means of transport to the user medium.

Interoperability is a characteristic of a product or system whose interfaces are fully known so that it can co-operate with other current or future products or systems without any restrictions, whether in implementation or access.

The following description refers to the definition of interoperability within (((eTicket Deutschland:

The guarantee of both a continuous journey and selective individual journeys for the passenger using the same user medium with the same application in the networks (fare management systems) of all contractually integrated transport companies. Read more about interoperability here.

In interoperable systems, a large amount of data must be exchanged between the various system partners in different individual systems. This task is performed by the interoperability network. It frees the operational units (application publisher, control and revocation list service, product owner, customer contract partner and service provider) from having to be informed about the details of the data transfer.

The interoperability network (ION) itself refers to the entire network that is logically and physically required to send messages between subscriber systems throughout Germany.

The cardholder is the person who has actual power of disposal over the card. If the card is used, the cardholder becomes the card user. The cardholder is the owner of the card. He is not necessarily the cardholder.

The term card type is used in KA to distinguish between different technical versions of a chip card (e.g. credit card, card with Mifare emulation, etc.).

The name Kernapplikation (KA) stands for the Germany-wide standard for electronic fare management systems for different public transport or system operators in versions 1 and 2. The new name (((etiCORE refers to version 3. Both standards cover security, certification, organisational concept and relevant system interfaces in e-ticketing, which allows the interoperable use of a public transport application on a user medium.

It defines

- the realisation of the specification on a chip in a user medium and its interface to the necessary acceptance terminals

- the description of the necessary interfaces between acceptance terminals and background systems

- the description of the necessary interfaces between the background systems of different fare management systems and relevant instances

- the proof of standard conformity and security through a certification procedure

Key management concerns the entire handling of cryptographic keys, i.e. the generation, distribution, administration, storage, replacement and monitoring of cryptographic keys (see also symmetric key/asymmetric cryptography).

In Germany, these tasks are ensured by the Scheme Manager (which only covers one aspect) and are performed by a central instance, the sub-role of the Security Manager. In (((etiCORE, the key management for the symmetric keys in the partner systems of the product owner and customer contract partner is omitted.

The check verifies that the customer/user fulfils all the requirements necessary for the use of a public transport service:

- readable customer medium,

- valid application (including check of the blocking list for applications)

- valid authorisation (including check of the blocking list for authorisations)

- valid product (tariff validity)

It is primarily in the interest of the public transport service provider, who invoices its services on the basis of proof of performance. If one of these conditions is not met, the check initiates the increased transport charge. The control also initiates the blocking of an application or authorisation on the customer medium if corresponding blocking entries are found on the blocking list. From 2GSI / (((etiCORE, blocking on the user medium can be carried out without SAM.

In 1GSI / KA 1.X, a proof of control is written to the user medium in addition to being sent to the product owner; from 2GSI / (((etiCORE, the proof of control is only sent to the product owner. This means that from 2GSI / (((etiCORE, inspection is possible without SAM. In terms of ISO 24014, the inspection can be understood as part of the recording, but is an independent use case.

The control and revocation list service (KOSE) provides lists with revocation entries for

- authorisations

- Applications

- Secure Application Modules (SAMs)

- keys

- organisations

Entries in the dedicated lists indicate that the referenced instance is stolen, compromised, invalid, etc. For all these instances, new commands can be executed to add an entry to these hotlists or to remove an entry from these hotlists:

- by the Scheme Manager in relation to organisations, SAMs and keys (in (((etiCORE only authentication keys)

- by the customer contract partners with regard to applications and authorisations

In addition, as part of Collecting and Forwarding (see ISO 24014-1), revocation credentials (relating to either an authorisation or an application) are processed by being collected by the service providers and made available to the product owners (authorisations) and the application issuer (applications). See role model in Spec Main.

Carrier of the application. See also user medium.

Customer data is the generic term for customer preferences and the customer profile.

Individual, selectable customer details that are stored in the application on the customer medium and can be used, for example, to speed up check-in. They are not automatically relevant to the contract. These are preferred ticket characteristics.

All of the personal master data describing the customer that is stored in the application on the customer medium. Due to its specified data structure, the customer profile can be interpreted in the same way for all interactions with the application. However, it can be used on an operator-specific basis.

Customer service is defined in ISO standard 24014-1 and realises comprehensive information and complaint management for every customer in connection with the VDV core application, including stolen or damaged user media. This includes call centre functions, internet service and can take place via regional service points.

A customer contract within the meaning of (((eTicket Germany represents a relationship between the transport company providing the customer with a service and the customer. The customer contract describes the conditions under which the customer can use the services offered by the transport operator. At the same time, the customer is granted the right to utilise a service. The customer contract regulates the fare calculation and billing between a customer contract partner and a customer. The customer contract primarily defines the user tariff parameters to be applied.

The customer contract is always qualified by the organisation ID of the customer contract partner. The customer contract is stored in electronic form as an authorisation (as (((e-payment authorisation or electronic ticket) on the basis of an EFM product defined by the product owner on the public transport application.

The role of the customer contract partner is a special role in the core application. It consists of several roles defined in ISO 24014-1:

- Product Retailer

- Application Retailer

- Customer Service

- Identity Provider

- Account Provider

- Payment Provider

The customer contract partner regulates the customer's sales processes, taking into account the contractual dependencies with the scheme manager and the product manager of the various mobility services. In particular, the customer contract partner is responsible for the accounting, ticketing and billing of the various mobility services to the customer.

He therefore assumes the role of Product Retailer, Application Retailer (instance issuer) and Account Provider. As an account provider, it utilises the services of payment providers of its choice with which it has a contractual relationship. The customer contract partner can act in the role of primary customer contract partner or in the role of third-party customer contract partner. See role model in Spec Main.

The customer contract partner personalisation unit encapsulates the communication between the user medium and the SAM. It therefore consists of at least one read/write device with SAM.

If a user medium is to be printed in the form of a chip card, the corresponding printer is also part of the CIP-PE. For example, a lettershop machine in a mass personaliser is ultimately also a CIP PE.

The customer contract partner sales unit (KVP-VE) provides the software for the selection of applications for personalisation, authorisations and communication with the reference background system and provides the necessary input and output components (monitor/keyboard).

The proof of service represents the service data stored on the user medium for control purposes, which describes the customer's service utilisation in the IN-OUT system.

First security level in the security architecture of the VDV core application (in (((eTicket Germany). In Level 1, a very limited number of organisation IDs are used, which are used as examples for all participants in their roles for the certification of system components. These special organisation IDs are designed in such a way that they are not recognised by any effective system. For the very first tests in the development of system components, it is recommended to work at this level-1.

Second security level in the security architecture of the VDV core application (in (((eTicket Germany). In level 2, all KA security components (symmetric / asymmetric keys, SAM and user medium) are generated and used with organisation IDs, which are assigned as a complement to the active or level 3 organisation IDs assigned to the participants.

In KA version 1.X, the first bit in the 2-byte organisation ID is replaced for this purpose. As a result, a value of 8000 hexadecimal or 32768 decimal is added to the level 3 organisation ID. For example, the organisation 5600 decimal or 15E0 hexadecimal then becomes the organisation ID 95E0 hexadecimal or 38368 decimal in level 2.

In (((etiCORE, the level is no longer controlled via the organisation ID (which is not set to 2 bytes) itself, but via the certificate used. This means that the organisation IDs in level 2 and level 3 are the same, and only the security management or the output of the certificates controls how the current system environment may be used.

Third (highest) security level in the security architecture of the VDV core application in (((eTicket Deutschland. In Level 3, all KA security components (symmetric / asymmetric keys, SAM and user medium) are generated and used with the Level 3 organisation IDs, which the participants use in their KA systems for unique identification, authentication, encryption and transaction security.

All security components for end-to-end protection of participant interests are protected here and cannot be accessed by third parties. Level 3 is reserved for active operation. In active operation of (((eTicket Deutschland, only value objects (e.g. (((ePayment authorisations) that have been created with Level 3 organisation IDs are used and recognised. Only Level 3 certificates may be used for the (((etiCORE standards.

A proof authentically logs a transaction at user medium level. This can be the issue of an authorisation, check-in or check-out, proof of control, blocking, unblocking, cancellation, charging of value units, etc.

Emergency versions are used to limit failures and (financial) damage if a key is compromised. In effect, this means that emergency keys are stored in the application in addition to the respective keys when the application is personalised. It is possible to switch to these emergency keys during operation.

From (((etiCORE onwards, the term is no longer used, as a different mechanism is used for the use of a different key following a key compromise. See Symmetric key.

The user is in possession of the user medium and is the traveller (passenger) within the meaning of ISO 24014-1. They use the public transport service of a specific fare product. In contrast to the customer, the user can also participate anonymously in (((eTicket Germany.

s. Kundenmedium / Customer Medium.

User tariff parameters can be changed by the application user at terminals compared to a valid contract of carriage for a journey for which the changed parameters then apply (e.g. take-along regulation or change of service class).

The usage counters are used to grant customers special fares based on the transport services they use in the case of automated fare calculation. With post-priced fare calculation, a best price or bonus scenario can also be realised without usage counters.

With trip-priced fare calculation in combination with the use of a value unit authorisation, however, the usage counter is required in order to grant special fares on the transport services used (e.g. calculation of a day ticket from the fourth single journey).

s. Asymmetrische Kryptographie / Asymmetric Cryptography

The public transport service provider offers transport services for a customer who has acquired a corresponding authorisation to use these services. The transport contract is concluded between the transporting public transport service provider and a user/passenger when boarding the means of transport.

The service provider acquires the right to participate in the EFM system from the scheme manager, regulated in a contractual relationship (((eTicket participation contract). The public transport service provider concludes contracts with the product managers for the acceptance of products and for the payment of the transport services provided, as well as with the customer contract partners for the settlement of the receivables incurred (via receivables clearing).

See also role model in the Spec-Main (for KA 1.X Spec HD BOM).

Earmarked value units paid for by the customer that are used for the cashless use of transport services. The public transport value units are purchased against valid and accepted means of payment at authorised public transport points, stored in the public transport application and successively debited from the memory at authorised public transport terminals in accordance with the (transport) services used. The public transport value units correspond to a multi-ride quota for public transport.

The organisation ID uniquely identifies an organisation within the entire scope of the core application. The organisation ID consists of the organisation number, which is assigned by the Scheme Manager (VDV ETS) registration via the ASM tool when an (((eTicket contract is concluded. The organisations assigned an ID are legal entities, typically transport companies and associations. In exceptional cases, these can also be clearly demarcated operating units of a large company.

A Personal Identification Number (PIN) is a numeric (or less commonly: alphanumeric) passcode used to authenticate a user accessing a system.

Specifically used as part of the core application: Four-digit secret code that can be used to read customer data on the user medium. This customer data may only be read out either authentically by authorised terminals or by the customer himself using his PIN.

Personalisation in the sense of (((eTicket Germany means adding personal data to the application of the user medium. This creates a customer profile and, where applicable, customer preferences. The technical processes for this are described in the specification of the user medium.

The term "personal" is usually used in connection with authorisations and means that an authorisation is only valid for a specific person and is not transferable.

Public Key Infrastructure (PKI) refers to a system that can issue, distribute and verify digital certificates. The certificates issued within a PKI are used to secure computer-based communication. The PKI is used in the field of asymmetric cryptography.

Refers to an account through which public transport services used by the customer are charged via the prepaid payment authorisation (PEB). For the autoload option, an agreed amount of money can be topped up against a customer account of a credit institution known to the customer contract partner when a contractually agreed threshold value is reached. The public transport services used via the authorisation are collected independently of the personal customer data and charged promptly via this account. There is at least one customer contract for each prepaid account.

Note: Setting up an anonymous prepaid payment method (without autoload) would be possible in principle, but is not currently planned as part of the core application.

The primary customer contract partner issues an application or authorisation. Its organisation ID is entered in the application or authorisation to enable the application or authorisation to be assigned to the primary customer contract partner who issued it.

Refers to an account via which public transport services used by the customer are settled via the postpaid (((e-payment authorisation (POB) against invoice or via a customer account of a credit institution known to the primary customer contract partner. The public transport services used via the authorisation are collected independently of the personal customer data and charged via this account at a contractually agreed time. There is at least one customer contract for each post-paid account.

It is not possible to set up a post-paid payment procedure anonymously.

The term product is used in the core application in the sense of a public transport fare product or EFM product.

Product clearing (PCL) is a centralised system that forms a Germany-wide fare server and knows and can calculate all fares of the connected participants via fare modules according to PKM. Product Clearing determines the correct fares and prices for the customer's travel chain.

The PCL uses the PKM fare modules to calculate fares. This open standard for the digital mapping of fare data is part of the VDV core application and not only provides information on product-related enquiries, but also calculates the correct fare product for the journey based on the specified user fare parameters.

All product managers involved in (((eTicket Deutschland make their current fare module available to the system. This creates a central point for all fare data in Germany.

The product owner develops EFM products from its tariffs for transport services in one or more geographical areas in which various public transport service providers offer transport services. The participation contract regulates the necessary modalities between the product owner, the customer contract partners and the public transport service providers. The product owner acquires the right, regulated in a contractual relationship, to participate in the EFM systems from the scheme manager and to register its products there. They receive the necessary identifiers and information from the Scheme Manager to manage their tokens, rights and security modules.

As part of security management, the product owner authorises the customer contract partners to issue authorisations. The product owner authorises customer contract partners to sell their products.

See also role model in Spec Main (for KA 1.X Spec HD BOM)

The reference authorisation provides a defined structure that can be used both as an automated travel authorisation and for an electronic ticket. On the one hand, it represents a recommended specification for an automated travel authorisation with firmly defined product-specific structures for interoperable use.

On the other hand, the reference authorisation for an Electronic Ticket is a proposal with firmly predefined product-specific structures that can be used by the product managers when implementing eTickets. Alternatively, the TLV-EFS offers a somewhat more flexible and memory-optimised default here

The reference system is an imaginary system, the reference terminal an imaginary terminal that combines defined basic functionalities. These basic functionalities can be found in real use in various systems or the terminal types associated with the system. The functionalities realised in the real system or terminal are implemented there analogous to the use cases in the system specifications (from (((etiCORE: KVP-Ref - Dienstleisterumgesetzt.

An instance within the Public Key Infrastructure to which persons, machines or subordinate certification authorities can apply for certificates. The RA checks the accuracy of the data in the requested certificate and approves the certificate request, which is then signed by the certification authority (CA).

The Registration sub-role of the Scheme Manager is responsible for generating, organising and taking responsibility for the identifiers required in the system for interoperable use, as well as for managing the contracts required for organisation and operation.

The regular version of a (symmetric) key can be used as long as the key is not compromised. From (((etiCORE onwards, the term is no longer used, as a different mechanism is used for the use of a different key following a key compromise. See Symmetric key. See also emergency version.

The Scheme Manager is the highest instance of (((eTicket Deutschland. This task is performed by VDV ETS. The Scheme Manager combines the roles of application issuer, registration and security manager from ISO 24014-1.

It creates the regulations and monitors them. It exists once in the system and identifies itself uniquely. Further information can be found in the role model of the main specification.

The key register belongs to a special function of the application on the user medium. It is required in connection with the issuing of authorisations (in this context, the misleading term of multi-authorisation is used*.

The keys used can already be protected for the issuing customer contract partner and the intended product owner when the application is issued. These keys depend on the instance ID of the application, but not on an individual authorisation ID. Additional keys can be entered for other customer contract partners or product owners if required.

When an authorisation is issued, the required key references to the existing keys are then entered in the key register; matching keys between the user medium and the terminal for issuing an authorisation considerably speeds up the process. The authorisation issued in an application with a key register does not differ technically from an authorisation in an application without a key register.

As of (((etiCORE, the use of a key register in connection with the issuing of authorisations in this form is no longer necessary due to the faster cryptographic processes. However, there is a new key register used for authentication in a similar form, in which the references to the generations of authentication keys are stored, see also Symmetric key.

*The term multi-authorisation suggests that multiple authorisations could be involved, which can be used for different services. However, this term only refers to the fact that keys can be used for several authorisations in order to save time for cryptographic processes during access. Multi-authorisation itself is no different from normal authorisation.

The Secure Application Module (SAM) is used as a security module for customer contract partners or service providers and executes the security-relevant functions of the sales terminals and/or control terminals that communicate directly with user media. It can also be used to check the transaction signatures generated with the user medium in the background systems.

The Secure Crypto Environment (SCE) is a logical component on a passenger's mobile device that is able to receive (or generate) and use cryptographic keys and bind them immutably to the mobile device and a ticketing app.

The SCE must be resistant to the keys being read and copied to another mobile device and can use the backend to authenticate keys. Technically, it can be implemented, for example, as a library that is integrated into a ticketing app and utilises the security resources of the mobile device such as a hardware-based key store.

The security architecture of the core application comprises 3 different security levels for test and live operation, which relate to the use of user media, SAM, symmetric and asymmetric keys and the associated certificates. The security levels and the associated production environments at the security service provider are completely separate in order to avoid any security risks. In accordance with the separate security levels, a participating company receives two organisation IDs for KA Version 1.X, one each for Level 2 and Level 3. For (((etiCORE, corresponding certificates are used for the different security levels.

The lock request is intended to cause an object to be placed on the respective lock list by a responsible third party. There are different parties involved depending on the object:

- Request made to the responsible customer contract partner to have an authorisation placed on the revocation list. This can be initiated by another customer contract partner, public transport service provider or product manager.

- Request made to the responsible customer contract partner to have an application placed on the blacklist. This can be done by another customer contract partner, a public transport service provider or the application publisher.

- Request made to application issuers to have a Secure Application Module, a key (from (((etiCORE only authentication keys) or an organisation placed on the respective revocation list. This can be initiated by another customer contract partner, public transport service provider or product owner.

The revocation request is intended to cause the removal of an object from the respective revocation list by a responsible third party. There are different parties involved depending on the object:

- Request made to the responsible customer contract partner to remove an authorisation from the revocation list. This can be initiated by another customer contract partner, public transport service provider or product owner.

- Request made to the responsible customer contract partner to remove an application from the revocation list. This can be initiated by another customer contract partner, a public transport service provider or the application publisher.

- Request made to the application issuer to remove a Secure Application Module, a key (no longer from (((etiCORE) or an organisation from the respective revocation list. This can be initiated by another customer contract partner, public transport service provider or product owner

The lock request is used to add an object to the respective lock list. There are different initiators depending on which object is to be added:

- The responsible customer contract partner issues the order to add an authorisation or an application to the revocation list.

- The Scheme Manager orders the addition of a Secure Application Module or an organisation to the revocation list.

- The key holder (customer contract partner, product owner or scheme manager) orders the addition of a key (from (((etiCORE only the scheme manager as the key holder) to the respective revocation list.

The lock release request is used to remove an object from the respective lock list. There are different initiators depending on which object is to be removed:

- The responsible customer contract partner issues the order to remove an authorisation or an application from the revocation list.

- The Scheme Manager orders the removal of a Secure Application Module or an organisation from the revocation list.

- The key holder (customer contract partner, product owner or scheme manager) orders the removal of a key (as of (((etiCORE, a release order from the scheme manager for keys is no longer possible) from the respective revocation list.

The blocking reason indicates why a block has been/is to be imposed.

A revocation list consists of a set of revocation list entries for a specific object (authorisation, application, SAM, key, organisation). It is used (after appropriate distribution in the systems/terminals) to detect unauthorised use of an application or authorisation to be blocked for the use of traffic services.

Based on the blocking list and its blocking list entries, a physical block (for authorisations and applications) or a logical block or the rejection of an authorisation or application (due to SAM, key or organisation blocking entries) is carried out.

A revocation list entry is created by adding an object to be revoked (application, authorisation, organisation, SAM, key) to the revocation list.

A revocation certificate is created by checking the application and authorisations against the corresponding revocation lists if a relevant revocation list entry is found. The subsequent physical blocking of an application or authorisation is documented by an authentic blocking certificate, which is also sent by the terminal to the responsible instances via a message.

Locking objects in the context of the KA are applications, authorisations, organisations and keys (symmetric/asymmetric). The administration of the revocation objects is the responsibility of the authorising instance. They are represented in revocation lists by an entry with at least their ID.

Applications and authorisations can be blocked and can then no longer be used as part of the core application. Blocking is based on a status change in the application or authorisation on the user medium In connection with mutual authentication between communication participants, a common key (the start key) can be agreed, which is used for secure communication between both partners. Further keys (session keys) can be derived from this by dynamisation. A key (session key) can be derived from basic keys through derivation and dynamisation, which is used within an encryption or MAC calculation or verification context.

The term static authorisation here refers to an electronic ticket equipped with a digital signature, which can be issued as an unchangeable data record on various, even simple media. This can be, for example

- a 2D barcode printed on paper or stored on a mobile device or

- a data record stored on a low-cost memory chip or NFC mobile phone and readable via an ISO 14443 interface

The same (secret) key is used by both communication partners for both encryption and decryption. Symmetric keys are used in KA 1.X both for mutual authentication of the components (keys come from the scheme manager) and for authentic proof of authorisation issues or payment transactions (keys come from the product owner and customer contract partner).

In order to be able to react quickly with key exchange in the event of key compromise and thus be able to work with a new key, KA 1.X works with regular and emergency versions of the keys. In (((etiCORE, all symmetric keys of product owners and customer contract partners are omitted. Only the symmetric keys for mutual authentication of the components remain in use.

Instead of regular and emergency versions, a key register with different key generations is then used. These key generations are already permanently attached to the components. If an authentication key is found on a revocation list, the terminal negotiates with the SAM and the user medium which authentication key must be used.

A tariff in the sense of public transport is a contract or a contractual component with a list of fixed conditions for the provision of services within the framework of a transport contract. The contractual conditions are called a tariff if they are offered unilaterally by a provider to many possible contractual partners (customers) in a standardised manner.

A fare product represents a standardised service offer for the use of public transport and is defined by the following characteristics:

- the service entitlement in terms of the service that can be called up (temporal and spatial validity, etc.)

- the type of product

- the legal transport conditions (e.g. eligibility criteria such as age (child/adult), status (e.g. student, pensioner), etc.)

- as well as the product price (fare) for the specific entitlement to benefits.

A tariff product can be extended by granting one or more additional benefits (Interservices, Intraservices) or by integrating special services (e.g. replacement in the event of loss) (see also customer contract).

Contract on participation in (((eTicket Germany. The participation contract governs the (((eTicket-specific rights and obligations of the (((eTicket Germany participants in their various roles among themselves (product owner, customer contract partner and service provider) and vis-à-vis the Scheme Manager (VDV ETS).

A ticket is the form of travel authorisation associated with a fare product within the meaning of public transport (ÖPV) in accordance with the applicable fare regulations. Each ticket reflects a concluded contract of carriage. A distinction is made between tickets that are valid immediately and tickets that must be validated or that cover a longer defined period of validity (season tickets). Tickets are stored in their entirety on the user medium as electronic tickets.

IN-OUT systems are a special case. In this case, a special fare product must exist, the terms of use of which the customer has agreed to in advance. During the course of the journey, the associated information authorising the customer to travel is generated on the user medium by means of check-in and check-out and saving. Tickets are qualified as an EFM product by a product manager and issued to the customer or user as authorisation.

Electronic ticket with TVL data elements defined in an annex to the KA BOM-Spec in the data structure Static Product-Specific Part and Transaction Product-Specific Part, which can be used variably to describe fare parameters. In KA Release 1.x, the Product-specific part transaction is not used for the TVL-EFS.

In computer science, a transaction is a sequence of programme steps that are regarded as a logical unit because they leave the database in a consistent state after error-free and complete execution. Therefore, a transaction must either be executed completely and error-free or not at all.

In the context of KA/(((etiCORE, transactions within the meaning of this definition take place exclusively between the user medium (in particular the chip card) and the acceptance terminal.

The delay time counter is an indication in minutes that represents a delay of the means of transport and corrects a restriction of individual tickets that are subject to a time limit accordingly.

The delay time counter is also important for IN-OUT systems if there is a corresponding delay when checking in again (checking in after continuing the journey) to another means of transport. By taking a delay counter into account, the new check-in can be counted as a continuation of the journey.

Collective term for all types of staff-operated and automatic peripheral sales devices for the sale of electronic tickets and for loading debit amounts as value units onto the user medium or into a prepaid account.

s. PT Value Units

The value unit authorisation (WEB) is the option or permission to use earmarked value units for public transport services on the public transport user medium. On the one hand, the value unit authorisation represents an automated travel authorisation in which a value unit memory is integrated. It has the advantage that it restricts access to an object in the user medium during automated on-trip fare calculation in the terminal and the transaction for the value unit booking is combined with the recording transaction (journey transaction).

On the other hand, it also represents an (((e-payment authorisation for public transport services outside of its use in IN-OUT systems. Depending on the customer contract, the following two usage options are available:

- WE-preload

This expression defines a procedure without an accepted overdraft of the WEB. A negative balance is not possible. It must have a defined, positive minimum balance before using the PPP. A public transport WE preload must generally be carried out before the public transport service is used.

- WE-postload

This term defines a procedure in which the balance of the WEB may fall into the negative (accepted overdraft) due to the debiting of public transport WE before or after the use of the public transport service. This procedure defines a maximum lower limit for the WEB balance, which is rejected by the system when reached. By adding the shortfall, the WEB is automatically balanced again the next time it is loaded.

A WEB allows anonymous participation in public transport, then in the WE-preload variant. An autoload function is possible for the value unit authorisation. However, anonymous participation in public transport is not possible in this case, as a contractual relationship is required for this.

s. Value unit authorisation / Stored Value (Unit) Payment Method

Synonym for the use of a user medium in IN-OUT systems that support read/write operations at distances greater than 20 cm. Usually in the BeIn-Be-Out context, e.g. with BlueTooth LE.

Switching centre belonging to the interoperability network (ION) that forwards messages from an ION subscriber to the recipient of this message based on the organisation ID specified as the recipient. The ION subscriber can be the application publisher, the control and revocation list service or a customer contract partner, service provider or product owner. These can be connected to this switching centre directly or via an adapter.

The "Certification" instance of the Scheme Manager is responsible for the standardised specification of the certification procedures required for the core application, for carrying out the certification of all system components and for issuing certificates for the relevant system components of electronic fare management.

Additional SAM-related certificate that is required to issue the VDV barcode based on the static authorisation. It is not supplied with the SAM ordered, but must be ordered additionally from the Trust Centre together with the SAM.

As of (((etiCORE, the SAM does not require an additional certificate for issuing VDV barcodes, but uses the certificate of its signature key for this functionality.