Interoperability & compliance of Keyple-based ticketing terminal solutions

In order to guarantee interoperability between smart cards and terminals, the ‘Calypso Networks Association’ (CNA) encourages ticketing operators to follow various specifications and certification processes.

Contactless reader communication protocol

For compliance with the contactless reader communication protocol, CNA supports the certification programme standardised by the ‘Smart Ticketing Alliance’ (STA) for ‘Public Transport Readers’ (PT Readers). Several test laboratories are approved for ‘Proximity Coupling Device’ (PCD) certification under the supervision of the ‘Certification Body’ Paycert.

Separation and functional logic of the various software layers

To guarantee the functional capability of the ticketing terminals, CNA has proposed a software architecture with a distribution of responsibilities per layer, and has defined dedicated functional requirements for each software layer.

Reader software layer

For terminals integrating contactless and/or contact readers, the Keyple’s ‘Core’ libraries have been designed to meet the terminal requirements for the reader layer. 2 conditions must be met to guarantee « complete » compliance with the requirements of the reader layer:

• the versions of Keyple’s core libraries must be compliant with versions 2.0 or higher of the terminal Reader APIs,
• & the plugins used to interface with smart card readers must follow the plugin development guide.

Pending the future certification programme for reader layer libraries, CNA plans to publish the self-declarations of conformity of the Keyple Core libraries for reader solutions interfaced with PC/SC and Android NFC plugins.

Properties of PC/SC and NFC reader solutions

Terminal requirements support declarations

With the exception of RF certification and ‘DF Name’ selection rules, all other terminal requirements defined by CNA for the reader layer, applicable according to the properties of the PC/SC or NFC reader solutions, are fully supported by default.

For “contactless” readers, the ‘RL-CL-RFSTA.2’ rule defines the need for the product’s RF properties to be certified according to the scheme defined by the STA.

• Most NFC readers are “self-declared” by by NFC reader manufacturers as compliant with the NFC Forum. This NFC declaration is recognized by the STA
• and thus implicitly considered as compliant with STA certification.
• By default, PC/SC contactless readers are not STA-certified.

‘Keyple Java Service sets’ definition

Calypso software layer

The Keyple’s ‘Calypso’ libraries have also been implemented to meet the terminal requirements for the Calypso layer, regardless of the reader solutions used. 2 conditions must be met to guarantee « complete » compliance with the requirements of the Calypso layer:

• the versions of Keyple’s Calypso libraries must be compliant with versions 2.0 or higher of the terminal Calypso APIs,
• & the reader software layer used as a basis (Keyple’s ‘Core’ libraries + reader plugins) must comply with the terminal requirements for the reader layer.

Pending the future certification programme for Calypso layer libraries, CNA has published the self-declarations of conformity of the Keyple Calypso libraries (independently of interfaced reader solutions, but on the basis of a compliant reader software layer).

Terminal requirements support declarations

For the various Keyple Calypso library sets, all applicabilities and terminal requirements are supported, with the exception of those listed in the table below.

• For requirements for which support is conditional on the availability of specific features, support has been integrated at the same time as the addition of the corresponding feature.
• Prior to the integration of Eclipse Keypop, Keyple libraries were based on terminal APIs implemented and published by CNA: the Keyple libraries sets corresponding to these old configurations contain the word “legacy” in their name.

For older configurations where support for the ‘CL-CSS-RESPLE.1’ requirement is indicated as “partial”: the countermeasure was initially implemented in a ‘permissive’ way, requiring applications to set only card commands for which the response size can be predetermined. More recent configurations benefit from a more ‘strict’ implementation of the countermeasure, which is compliant regardless of the processing set at application level as indicated in the Calypso development guide.

The lack of official support for the “HCE” functionality and the related ‘CL-SEL-SNHEADER.2’ requirement is not a limitation to correctly processing Calypso HCE solutions, as the HCE token data can still be recovered as described in the Calypso development guide.

‘Keyple Java Calypso Prime PKI set 2’ definition

‘Keyple Java Calypso Prime PKI set’ definition

‘Keyple Java Calypso Prime Extended set’ definition

‘Keyple Legacy Java Calypso Prime Extended set 2’ definition

‘Keyple Legacy Java Calypso Prime Extended set’ definition

‘Keyple Legacy Java Calypso Prime Regular set’ definition

‘Keyple Legacy C++ Calypso Prime PKI set 2’ definition

‘Keyple Legacy C++ Calypso Prime PKI set’ definition

Ticketing software layer

For a ticketing terminal solution built on the Keyple framework, the responsibility for complying with the requirements for the ticketing software layer lies exclusively with the developers of the terminal application using the ‘public’ Reader & Calypso terminal APIs.