Doc J011b

 DRAFT Report of the JCF GSM API Task Force #2
hosted by Gemplus in La Ciotat, 30 April 1998

1. GSM Framework

The main goal of the proposal in Doc J003 is to provide an API to the operator/developer to rewrite the GSM Application in Java. The proposal extends the JavaCard API, but it needs to rewrite an important part of it.

The purpose of that proposal is to provide the GSM requirements to the file system task force, so that JavaCard is redefined to reduce the overhead.

And as the SMG9 GSM API working party concerns are one level above the GSM Application, the group has decided to concentrate its efforts on the SIM tool kit layer first, even though it is considered important to incorporate the GSM requirements to the discussion around the file system issue for future implementation.

Several questions as those described in Doc J004, J006 should be submitted to the f file system Task force.

The following actions have been decided :- list of the GSM requirements out of the actual GSM API proposal to the file system task force. ((JPL, CDI)
- check status of the file system task force (SHI)
- define the GSM API after the file system class has been stabilized.
- define the SIM Tool kit framework (see below)

2. SIM Tool kit Framework

2.1 Overview

After some discussion the following diagram was accepted:

SM: stands for Selection Mechanism.

GSM: corresponds to the GSM application. It owns the GSM file/data, and handles all the GSM apdu. It is the "default applet" of the Selection Mechanism 1; in the future it might be written in Java.

Tool kit: it handles the tool kit protocol, providing services to the applet to construct proactive commands. The Selection Mechanism 2 based on the information provided by that layer will trigger the event from the corresponding Applet.

Applet: Can be any kind of applet either using the GSM/tool kit facilities or just handling APDU.

A more specific implementation might be :

2.2 Selection mechanism

Two selection mechanisms have been identified :

• SM1 which may correspond to the JCRE, will handle all the applet as defined in JC 2.0. It will be able to select any specific applet and send to it the corresponding APDU. The GSM application is the default applet.
  
   
• SM2 represents the GSM tool kit way to select an applet according to the event appeared in the lower layer ((GSM, Tool kit).). This SM may also need a default applet or behavior in case of missing a destination applet.

The SM has to be able to identify the addressed entity according to the content of the data. This content has to be defined at registration/installation.

For the registration 2 solutions have been identified:- explicit :  calling register method (e.g. Register ((Menu, "JCF SIM")..)
- implicit :  each applet has a list of entry points if it wants to handle it catches the event.

2.3 Applet

An applet may exhibit 2 interfaces, one to the GSM stack and the other to the SM1. This will allow an applet to handle application specific APDU instructions (e.g. banking terminal), and to use the tool kit features in a GSM phone.

This is a way to share data between different parts of a same application.

The GSM kernel handles the GSM APDU and forwards to the upper layer all tool kit related issues. The tool kit layer will then use a specific applet selection mechanism according to the event triggered to transmit the information to the corresponding applet.

The events that can trigger an applet have been described in Doc J001. This list needs to be revisited.

3. SIM Tool kit API

3.1 Tool kit API proposal:

• The proposal Doc J009 describes an API for GSM 11.14 : -
• proactive applet : as described above
• proactive commands : consist of a set of static methods
• a low level interface to handle proactive commands in a generic way
• a high level interface to ease the use of each proactive command
• proactive elements : the main class has some generic method and each simple TLV from the standard is a subclass.

The general ideas of the proposal were agreed to. There will be more detail in the working package 0 for next meeting (EBA)

For the handling of the terminal response 2 solutions have been proposed :

• either the applet implements a state machine to handle the tool kit protocol,
• or the applet uses the procedural programming model, and the framework handles the tool kit protocol.

This issue will be transmitted to the JCF for information.

3.2 GSM 11.11 API

Doc J005 is, in contrast to the Doc J003, not APDU-oriented but is an interface to all the GSM instruction, so that applets can have access to the GSM data as the external world, but without using the APDU.

Each applet should have its own GSM security context.

The proposal was seen as really positive and will be reviewed before integration in the working package 0. (JBO)

Additional work is requested for the access to GSM data. (JBO)

4. Working Package

The meeting tried to define 2 distinct names for the two API, to avoid any ambiguity. The current proposal is :

- GSM API: this will allow a rewrite of the whole GSM application at APDU level (GSM 11.11)

- SIM Tool kit API: this will allow the writing of applets above a tool kit framework which handles the tool kit protocol and the access to GSM data. (GSM11.11 & GSM 11.14)

Doc J002 proposed a certain number of working packages and deadlines. They have been reviewed according to the meeting.

WP0: GSM overall architecture proposal API framework
SIM Tool kit API GSM 11.11
Access to GSM application data

SIM Tool kit API GSM 11.14
Selection Mechanism
Proactive API

Loading

- end of May

WP1:

GSM API
requirements for JCF
proposal in line with new file system

SIM Tool kit API
Access to GSM data
data sharing mechanism requirement for JCF
- end of June

WP2: SIM Tool kit API

- end of July

WP3: Loading/installing

- end of August

5. Meeting Plan

Meeting	Date	Host	Location
JCF SIM API	02 June 1998	Schlumberger	Montrouge
-- Related meetings (for information) --
SMG9 API #4	during 19-22 May	Keycorp	Sydney, Australia
JCF	03-05 June	Schlumberger	Paris
SMG9 API #5	16 June 1998	IBM Research	Zurich, Switzerland

Annex A: List of Participants

Name	Organization	E-Mail
Barbier Eric	De La Rue	eric.babier@cards.delarue.com
Böhler Jürgen	Giesecke and Devrient	juergen.boehler@gdm.de
DIETRICH Christian	Schlumberger	dietrich@montrouge.ts.slb.com
HILD Stefan	IBM research	sgh@zurich.ibm.com
LE GALL Jean-Pierre	Gemplus	jean-pierre.legall@gemplus.com
Yvon Christophe	CNET/France Telecom	christophe.yvon@cnet.francetelecom.fr

Annex B: Document List

Doc No.	Title	Source	Status
J001	Applet Triggering proposal	De La Rue
J002	Working Package and document outline proposals for GSM API	Schlumberger
J003	GSM API proposal, APDU oriented API	Gemplus
J004	comments on GSM API Fabien Thiriet	Schlumberger
J005	GSM 11.11 interface	Giesecke & Devrient
J006	Suitability of the current SIM API for GSM files access	De La Rue
J007	Toolkit Applet management	Gemplus
J008	Applet Life Cycle Management	SMG9 SIM API / IBM
J009	proposal for the SIM tool kit API	Schlumberger
J010	table of content for template document	Schlumberger
J011	Report of the JCF GSM API Task Force #2

Java^TM is a trademark of Sun Microsystems

[Java Card Forum] [Charter] [Calendar] [Contacts] [Communications]
[Technical] [Business] [Memberships]

Webmaster