afpayments / qcat_qr_ticketing_standard

QR Public Transport Ticket Specification

QCAT TICKETING STANDARD

The QCAT standard and the associated documents define technical, operational and commercial specifications and rules for an interoperable ticketing system using QR Tickets. In addition to studying the standard, you can participate by making comments, asking questions or contributing improvements. For more guidance how to contribute see Contribution Guidelines and Code of Conduct

Table of Contents

• What is the QCAT Standard?
• What is the QCAT Ecosystem
• What does QCAT stand for?
• How does the beep(tm) system relate to QCAT?
• Under what terms does AFPI license the QCAT specification?
• What does Interoperability in the QCAT Ecosystem mean?
• What roles exist in the QCAT Ticketing Ecosystem?
  • QCAT Ticket Issuer
  • QCAT Ticket Acceptor
  • QCAT Ticket Creator
  • Passenger
  • Public Transport Operator
  • QCAT Certificate Authority
  • QCAT Registrar
• What is the role of AFPI in the QCAT Ticketing Ecosystem?
• How can my company participate in the QR Ticketing Ecosystem
  • QCAT Ticket Issuer
  • Equipment Vendors
  • QCAT Ticket Acceptor
  • Transport Operators
• What do I need to do to become a participant in the QCAT Ecosystem?
• What is the difference between QR Code Ticketing and QR Code Payment?
• What is the Pre-paid QR Ticket Use Case?
• What is the Post-paid QR Ticket Use Case?
• What Data does the QCAT QR Code contain?
• Does AFPI offer test and certification services?

What is the QCAT Standard?

The QCAT standard is a set of specification and documents that define a QR code based ticketing system for automated fare collection in public transport.

The main part of the QCAT Standard is the QR code specification, which defines the content and format of the QR code payload of a ticket.

What is the QCAT Ecosystem

The QCAT Ecosystem describes the technical, operational and legal framework and practice of an interoperable QR code based ticketing system in public transport.

What does QCAT stand for?

We are sure that QCAT is an acronym for something we had in mind when we wrote the first versions of the standard, but we have forgotten what it is. Unfortunately, by now too many documents use the acronym to change it.

How does the beep(tm) system relate to QCAT?

beep(tm) cards use a different technology (NFC) and are not compatible with the QCAT standard. However, AFPI’s objective is for all acceptance systems to work with both beep(tm) cards and QCAT tickets.

Under what terms does AFPI license the QCAT specification?

The specification is publicly available and free to study but requires a license agreement for commercial and non-commercial purposes. Our aim is to make the QR Ticketing specifications as freely available as possible without jeopardizing interoperability (see What does Interoperability in the QCAT Ecosystem mean?).

Our license agreement would be based on the following principles:

• software and applications using the ticketing standard carry this license language and use the term “QCAT QR Ticketing Standard” to refer to the standard.

• the licensee does not use the standard to implement a proprietary, non-interoperable ticketing system, and

• the licensee will use the AFPI QR Ticketing Signature Authority to generate certificates to be used in ticket validation terminals

• the licensee does not offer or sell any product, system or solution that is based on the QCAT specification and the IP encapsulated in the QCAT specification to parties who have not accepted the QCAT specification license

see LICENSE

What does Interoperability in the QCAT Ecosystem mean?

Interoperability means that all genuine tickets generated by participating QCAT Ticket Issuers will be accepted in all QCAT validation terminals of all participating QCAT Acceptors.

Technically, interoperability is assured through

1. cryptographic signatures and a common QCAT Certificate Authority.

2. common identifiers managed by the QCAT Registrar

3. common standards for the content and encoding of data in the QCAT QR code

Commercially, QCAT Ticket Issuers and QCAT Acceptors must enter into commercial contracts to ensure that the QCAT Acceptors get paid for all correctly accepted QCAT Tickets.

Operationally, interoperability is assured by common dispute resolution principles that define what "correctly accepted" means and who is liable for the value of an accepted ticket.

What roles exist in the QCAT Ticketing Ecosystem?

QCAT Ticket Issuer

An entity who enters into a contract with a potential or current passenger, issues QCAT tickets to the passenger, collects the ticket price from the passenger and settles the ticket price with the QCAT Ticket Acceptor.

QCAT Ticket Acceptor

An entity who operates a system that is capable of validating tickets and that settles the ticket price with the respective Transport Operator and the QCAT Ticket Issuer.

QCAT Ticket Creator

An entity authorized by the QCAT Ticket Issuer to generate and/or sell QCAT tickets. The liability for the settlement of ticket prices remains with the QCAT Ticket Issuer.

The QCAT Registrar may issue a limited number of additional participant IDs to the QCAT Ticket Issuer to support the allocation of funds between QCAT Ticket Issuer and its QCAT Ticket Creators.

Passenger

A person buying and using a ticket for the purpose of using the services of a Public Transport Operator.

Public Transport Operator

An entity offering person transport services to the public (including defined groups such as residence of a ho9using estate or an industrial park)

QCAT Certificate Authority

An entity signing the Public Keys of QCAT Ticket Issuers, distributing the certificates to QCAT Acceptors and distribute certificate revocation lists to QCAT Acceptors

QCAT Registrar

An entity that maintenance a registry of reserved identifiers for use in QCAT tickets. Examples of reserved identifiers include Ticket Issuer Identifiers and Default Ticket Type Identifiers (e.g. Senior Citizen Ticket Type).

What is the role of AFPI in the QCAT Ticketing Ecosystem?

1. AFPI owns, licenses and manages the QCAT specification and materials.

2. AFPI operates the QCAT Certificate Authority that signs QCAT Issuer signature keys and distributes public key certificates to QCAT Ticket Acceptors in the QR Ticketing Ecosystem.

3. AFPI operates the QCAT Registrar for participants IDs of issuers of QCAT tickets and other identifiers used in QCAT tickets

4. AFPI operates as one of the QCAT Ticket Issuers, QCAT Ticket Creators and QCAT Ticket Acceptors

How can my company participate in the QR Ticketing Ecosystem

QCAT Ticket Issuer

Any organization willing to accept the terms of the QCAT License and that enters into commercial agreements with QCAT Acceptors may issue QR Tickets that are accepted in the QCAT Validation terminals of the QCAT Acceptors.

Equipment Vendors

Any company that develops software, hardware, systems or provides system integration services may use the QCAT specification to build compliant systems.

QCAT Ticket Acceptor

Any company that provides automated fare collection systems and/or services may use the specification to accept QCAT compliant tickets as long as the QCAT Ticket Acceptor accepts the terms of the QCAT license and enters into commercial agreements with QCAT Ticket Issuers.

Transport Operators

Any transport operator may participate as QCAT Ticket Acceptors and QCAT Ticket Issuers.

What do I need to do to become a participant in the QCAT Ecosystem?

Using the QCAT specification to develop solutions and systems does not require any further agreement with AFPI.

In order to use the QCAT based system in production, the QCAT Ticket Issuer or the QCAT Ticket Acceptor must enter into a license agreement for commercial use and an agreement with AFPI that will govern the use of the QCAT Certificate Authority and the QCAT Registrar.

Companies who would like their QCAT tickets to be accepted in validation and inspection terminals managed and/or operated by other participants in the QCAT Ecosystem, or companies that would like to accept QCAT tickets generated by by other QCAT Ticket Issuers participating in the QCAT Ecosystem , contact AFPI for a QCAT License and Ticket Issuance and Acceptance Agreement.

What is the difference between QR Code Ticketing and QR Code Payment?

in Automated Fare Collection, payment and ticketing are two distinct processes.

The ticket is used with ticket validator terminals that validate a ticket on entry and/or exit or during an inspection.

A ticket contains information for the validator or inspection terminal to decide whether the ticket holder is allowed to enter the vehicle or whether the ticket holder has paid the correct fare for the exit stop.

Payment on the other hand is the process to pay for the ticket. The payment can be done using one of multiple payment instruments such as cash, eWallet, store value card and so forth.

There are pre-paid tickets that have been paid for before the passenger starts their journey and post-paid tickets that are paid for after the passenger has left the public transport vehicle.

What is the Pre-paid QR Ticket Use Case?

The use case for pre-paid tickets is defined as follows:

1. Prepaid QR Code tickets can be printed on paper or generated and displayed on the phone

2. The passenger pays for the ticket before starting the journey. There are many possible payment scenarios, such as

   • The passenger presents a QR code generated by an e-Wallet provider or a bank to a special unattended terminal, which will use the QR code to seek authorization for the fare amount and then prints a pre-paid ticket.

   • The passenger uses cash to buy a paper ticket at an attended ticketing booth

3. The prepaid ticket may contain the price, the boarding station, the destination station, validity period and so forth.

4. In all cases the passenger presents the prepaid ticket at the boarding gate or ticket validator

5. The ticket validator verifies the validity of the ticket at the entry and possibly at the exit station

6. The AFCS provider and the ticket seller will settle transactions based on ticket validation reports.

What is the Post-paid QR Ticket Use Case?

The use case for post-paid tickets is defined as follows:

1. The QR issuer, at the request of the passenger, generates a QR code on the mobile phone that contains information about the account or identity of the passenger

2. the QR issuer potentially earmarks a certain amount in the passenger’s account.

3. The entry and exit validators verify the QR code and open the gate if the QR data is valid

4. The QT validators send the QR validation records (entry and exit) to the AFCS provider as soon as possible

5. The AFCS provider calculates the ticket price based on entry and exit station and generates a payment transaction including the amount and the QR code account or identify data. The payment transaction record is sent to the QR code issuer who debits the passenger’s account based on the data included in the payment transaction record.

What Data does the QCAT QR Code contain?

Please check the specification for the data elements defined for the QCAT QR code: QCAT specification

Note	The list in this FAQ may not be up-to-date!

Table 1. Mandatory Data Elements

Data Element	Explanation
Ticket Identifier	A number that is unique in combination with the time of creation and the ticket issuer id or with the identifier of the issuing terminal.
Ticket Creator ID	The ticket creator is the organization that is authorized to create tickets and that will be liable for the fare amount when the ticket is accepted by an AFCS provider. IDs are allocated by AFPI.
Time of ticket creation	Time at which the ticket was created. The ticket validity and QR refreshment periods are always interpreted with this time as the base.
Ticket Validity Period	Time period in seconds from the time of ticket creation after which the ticket is not valid anymore.

Table 2. Optional Data Elements

Data Element	Explanation
Ticket Validity Domain	Identifies the public transport facility on which the ticket is valid. Ticket domain identifiers are assigned by the ticket issuer and are unique only in combination with the ticket creator ID
Transport Operator Id	The identifier of transport operator for which the ticket is valid. There could be more than one operator ID in the QR code. Operators can be grouped and assigned a Ticket Validity Domain to avoid including too many operator IDs.
Ticket Effective Time	Time after which the ticket is valid. Default is the ticket creation time.
Refresh Time	Time after which the ticket need to be refreshed with a new refresh time and signature. A value of 0 or if the field is not included means that the QR ticket is static.
Ticket Type	Indicates a special processing rule that will be applied when calculating the fare.
Account identifier	The account identifier provides information about the passenger’s account with the funding provider. This account will be debited according to the fare table and ticketing rules. The account number may be created dynamically as a token that is valid only for a certain time or for a certain transaction. Backend system should therefore not rely on this identifier to group transactions. Must be present in post-paid tickets.
Boarding Station	The identifier of the boarding station or stop.
Destination Station	The identifier of the destination station or stop.
Vehicle Id	The identifier of the vehicle for the ticket is valid (e.g bus number).
Route Id	The id of the route for which the ticket is valid (e.g bus number).
Seat Number	The identifier for a particular seat that has been reserved for the passenger presenting this ticket. The format and meaning is operator or AFCS provider specific.
Seat Class	The identifier for a particular seat class. The format and meaning is operator or AFCS provider specific.
Maximum Authorized Amount	Amount in Centavos. If the fare amount is known when the passenger starts the trip, this field will be checked and the QR code rejected if the fare is higher than the maximum authorized amount. If the fare is not known at boarding time, the maximum remaining fare on the trip must be lower than the amount in this field. The funding provider may earmark this amount in the passengers account and release the unused funds when the correct fare amount is provided by the AFCS provider.
Signature Key Identifier	The key identifier is used to distinguish multiple public key certificates assigned to a single QR Issuer. It corresponds to the Common Name (CN) in the Issuer’s certificate. If present, the value in this field and the CN of the issuer certificate that is used to validate the signature must match. If this field is not present, the terminal will ignore the CN and use any certificate with the Ticket Creator’s ID.
Terminal Identifier	The terminal identifier identifies the device that "produced" the QR ticket. Validation terminals should always check the terminal ID, if present, together with the ticket ID and creation time to ensure that the same ticket is not used twice. The terminal ID should be unique in the ticket creator fleet of devices to the extend that the validation terminal is able to distinguish between two tickets with the same ticket identifier.
Signature	The signature proves that the the QR code was indeed created by the ticket issuer. The signature is calculated according to the algorithm that is described in this specification. The first byte contains a version number and the remaining bytes contain the signature value. Version numbers from 0x00 …​ 0x7F are reserved for this specification. Version number 0x80 …​ 0xFF can be used for proprietary algorithms. The default version number for the algorithm described in the specification is 0x01, which stands for SHA512 with RSA.

Does AFPI offer test and certification services?

AFPI is leasing or selling validation terminals and test keys that can be used to verify the accuracy of generated QCAT tickets. AFPI can also validate a limited number of QCAT tickets that are sent via e-mail.

Based on separate commercial agreement, AFPI can also provide test services for validation and inspection terminals. Contact AFPI for details.

AFPI also provides consulting services for any organization who develops or uses or plans to use or develop QCAT based systems.

qcat_qr_ticketing_standard's Issues

Additional field : Payment Type

This is to request an additional field to captures the payment tenders on the issuing.

ENHANCEMENT: Design for tickets that are valid for multiple operators on the same route

Tickets Valid for Multiple Operators

The specification should clarify how a ticket can be issued for acceptance at multiple operators.

The Problem

Let's assume we have a route R1 that is serviced by 3 operators O1, O2, and O3 that are associated in a consortium. The ticket issuer would like to issue a ticket that can be used from station A on any bus on this route R1 regardless which operator operates the specific bus the passenger is taking.

The operator IDs of the three operators are O1: 101, O2: 102 and O3: 103.

To achieve this, the ticket issuer could include all three operator IDs in the ticket. This is a valid solution only if all three operators use the same stop ID for the same stops. For example, if all three operators use stop ID 20 for station A, the ticket would contain operator IDs [101, 102, 103] and stop ID [20].

However, it is possible that the three operators service other routes and assigned ID 20 to another stop already and therefore each may assign a different stop ID to station A on route R1. Now the ticket would contain operator IDs [101, 102, 103] and stop IDs [1, 2, 3] and it is not possible to know which stop ID belongs to which operator (because the BER encoding of a TLV data structure does not gurantee the order of fields).

Solutions

Custom Validity Domain

The operators could ask the QCAT Registrar to combine the three operators into a custom validity domain D1, for example with ID 0x8001 and assign a new stop ID 1 to station A.

Assign Participant ID (aka Operator ID) to Operator Group

The operators could ask the QCAT Registrar to issue a new operator ID to the three operators, for example with ID 104 and assign a new stop ID 1 to station A, which is unique in combination with operator ID '104'.

Change of QCAT specification

The QCAT specification could be changed to allow pairs of operator id and stop ID.

Example for ticket with two operators and two boarding stops, which is ambiguous and currently not allowed

T: 63 (3/APPLICATION/Constructed: Application specific transparent template)
L: _ (_)

    T: C6 (6/PRIVATE/Simple: Transport Operator Id)
    L: 01 (1)
    V: 65 (101)
    ------
    T: C6 (6/PRIVATE/Simple: Transport Operator Id)
    L: 01 (1)
    V: 66 (102)
    ------
    T: CB (11/PRIVATE/Simple: Boarding Station)
    L: 01 (1)
    V: 01 (1)
    ------
    T: CB (11/PRIVATE/Simple: Boarding Station)
    L: 01 (1)
    V: 02 (2)
    ------

Example for a ticket with one single boarding stop that has a different ID for operator 101 and 102

T: 63 (3/APPLICATION/Constructed: Application specific transparent template)
L: _ (_)

    T: E1 (1/PRIVATE/Constructed: Unique Boarding Stop)
    L: 06 (6)
        T: C6 (6/PRIVATE/Simple: Transport Operator Id)
        L: 01 (1)
        V: 65 (101)
        ------
        T: CB (11/PRIVATE/Simple: Boarding Station)
        L: 01 (1)
        V: 01 (1)
    ------
    T: E1 (1/PRIVATE/Constructed: Unique Boarding Stop)
    L: 06 (6)
        T: C6 (6/PRIVATE/Simple: Transport Operator Id)
        L: 01 (1)
        V: 66 (102)
        ------
        T: CB (11/PRIVATE/Simple: Boarding Station)
        L: 01 (1)
        V: 02 (2)

ENHANCEMENT: Define ticket validity period from effective time if effective time is present

The expiry time is defined with the ticket creation time as a base, which makes it awkward to define an expiry period from the ticket effective time.

If an effective time is included in the ticket it is likely that the ticket creator would like to define a validity period from the effective time and from the creation time. Therefore the specification should be changed as follows:

8.2.1.4. Ticket Validity Period - "Time period in seconds from the time of ticket effective time if effective time is included in the ticket or from creation time if not. After the validity period is over the ticket is not valid anymore."