keyple

Keyple Core Application API

version 0.9 (current ‘develop’ branch)

Reader Access

With Keyple, smart card readers are managed through plugins in order to integrate specific reader solutions. The singleton Secure Element Proxy Service provides the unique name list of registered plugins. There are three kinds of plugin:

A reader is identified through its unique name in a plugin. There are two kinds of reader:

(The SE APDU transmission is managed at the low-level plugin API through the ProxyReader interface.)

Specific Plugin

To hide plugin native implementation classes, the reader plugins are registered to the SE Proxy Service through related specific plugin factory. Specific Plugin v0.9

Reader Notifications

Reader Notifications v0.9.0

Plugin event

Several ‘Plugin Observers’ could be registered to an Observable Plugin. In case of reader connection / disconnection, the observable plugin notifies sequentially the registered observers with the corresponding plugin event. The observable plugin is a blocking API, the thread managing the issuance of the plugin event waits the acknowledge of the observer currently notified.

Reader event

Several ‘Reader Observers’ could be registered to an Observable Reader. An observable reader has the capability to be set with a ‘Default Selections Request’: in this case when a SE is inserted in the reader, the reader will try to operate the configured different default selections. If a selection successfully matches with the SE, instead to simply notify the insertion of SE, the observable reader will notify about a successful selection with a SE application.

When the processing of an inserted or matched SE is finished, a reader observer has to notify the observable reader in order to prepare the observable reader to detect the removal of the SE.

Several ‘Reader Observers’ could be registered to an Observable Reader. In case of SE insertion / match / removal, the observable reader notifies sequentially the registered observers with the corresponding reader event. The observable reader could be a blocking API, the thread managing the issuance of the plugin event could wait the acknowledge of the notified observers.

Observable reader states

An observable reader is active only if at least one reader observer is registered. When active, an observable read could switch between four internal states: ‘Wait for Start Detection’, ‘Wait for SE Insertion’, ‘Wait for SE Processing’, & ‘Wait for SE Removal’.

The states could be switched:

If a SE detection is started with the ‘repeating’ polling mode, then later when the SE is removed, the reader starts again to detect a SE.

Whatever the plugin of observable reader, when waiting for the SE removal, any observable reader shall have the capability to notify the remove of the SE. Some reader plugin solution could have the capability to notify a SE removal also during the processing of the SE.

Observable Reader States

SE Selection

Selection scenarios

Depending on the SE transaction use case, or on the reader capability, there are two ways to manage the selection of a SE:

Selection v0.9

Selection setting and processing

A SE Selection request is defined with a SE Selector. A SE Selector could be defined with tree optional levels of selection filter.

Depending on the Keyple SE extension library, a SE request could be completed with specific SE commands to operate at the selection (for example, a Select File for a specific DF LID, the read of a specific file).

For terminal managing several kinds of SE applications, a SE Selection could be prepared with several SE selection request to operate sequentially with the SE.

According to the defined ‘multi SE request processing’ mode, the SE selection could stop at the first selection request matching SE application, otherwise all the prepared SE selection request could be operated.

The result of a SE request selection is a card image of a matching SE. For a SE selection with multiple requests, several matching SE could be provided.

SE Selection v0.9