The “Data-Structure” part

This part of the application profile is first of all very important for native cards. Indeed, the file system of the card can be represented within this section using the properties of XML:

Example:

<Entity type = “Root”>

<Entity type = “DF” ID = “101”>

<Entity type = “EF” ID = “301”/> <Entity type = “EF” ID = “302”/> </Entity>

</Entity>

This sample profile extract can be seen as the following file system within the card:

Root

DF

EF EF

Elementary File, Identifier = 301 Elementary File, Identifier = 302 Directory, Identifier = 101

Figure 9: Sample file system

Thus, the XML concept appears to be the most natural way for describing such structures. And even if this aspect is not a particular requirement for open platform cards (in this case the file system is hidden by the card and the card entities are on the same level of hierarchy), it would be considered as a high level concept usable for any type of cards.

Indeed, since the objective is to find a generic and extensible model for the card description, it is better to have as much information as needed, even if it is not one hundred percent used by all types of cards.

Moreover, this modelling part is not only useful for structure description but is also used during the script generation to easily retrieve the commands logic.

Indeed, one of the commands dependencies is the selection mechanism that must be hidden from the user: In order to communicate with a specific on- card entity, it must first be selected [OPCS]. For native cards, this selection might include the selection of the parent entity.

Thus, using an XML interface to retrieve each card entity described in the profile would provide an easy access to the parent, which allows the implementation of a generic algorithm for entities selection.

Example: Let’s assume that one of the requirements of the card operating system is the selection of each parent of the entity starting from the root. The data-structure facilitates the definition of a recursive algorithm for the selection mechanism:

/*High-level function describing the selection mechanism*/ - Function SelectAll (Entity toSelect)

If toSelect ≠ Root

Then SelectAll (toSelect.getParent ()) Select (toSelect)

This descriptive example shows that the definition of a data-structure within the profile, allowing the navigation throw the entities hierarchy, is a very important aspect of the modelling.

Indeed, it would be used to access the architectural information of the card model and improve the dynamic generation of the commands involved in the personalization.

4.1.1.1.2 State Modelling

This design strategy remains however very static. The architecture of the model required for the card is well defined, but there is no information describing the state of the smart card, and linking this model with the actual card state.

In order to understand the importance of this aspect, let’s consider the following example:

The configuration is very simple because the aim is to understand the “state modelling” concept: We assume that the card used is open platform and that it was already pre-personalized, with an applet inside i.e. that a specific applet has already been loaded on the card.

The diagram on the left describes the real state of the card (before or after the personalization process i.e. after script execution), and the one on the right represents the application profile with the modelling made by the user.

This approach is important in order to understand the differences between the modifications made on the model and their impact on the real state of the smart card.

Applet1

State of the card

Applet1

Application Profile

At the beginning of the modelling process, a starting profile template should be available. This template describes the actual state of the card and is independent from the different user modifications.

As shown in the figure above, the two diagrams represent the same starting state, which is important to avoid the definition, in the application profile, of the entities that already exist on the card.

Let’s assume now that the user wants to delete the existing applet and load a new one inside the card.

The user would first of all “delete” the existing applet and then “add the new entity”. Without the concept of state modelling, the result would be the one shown in the figure below: An application profile with another applet. This profile however cannot be used during the script generation.

Indeed, the commands sent to the card should also follow the actions-logic made by the user: First, send the command to the card in order to delete the old applet, and then load the new one. In the application profile however, there is no reference to the old applet.

Applet1

State of the card

Applet2 "NEW"

Application Profile

A possible solution for this problem is to add an action reference inside the data structure.

In the example, if the user wants to delete the first applet, all the information related to the entity would be kept within the profile and the action would be “delete”.

For the new applet, the action would be “create” or “load” (according to the naming convention).

This approach models not only the user requirements, but also the on-card entities that might be modified during the personalization process (the modification could be delete, change entity data…).

Thus, during the interpretation of the profile, the high-level actions that should be done during the personalization (create, delete, update) are quickly recovered by the interpreter. For the “unchanged” entities, the action field would be set to “NONE” which would avoid the time consuming treatment of this kind of card elements.

The figure below shows the new application profile after the “delete applet 1” and “create applet 2” requests.

Applet1

State of the card

Applet2 To load Application Profile

Applet1 To delete

The new defined application profile can be used to retrieve the actions logic that has to be performed on the card, and to reach the card state described in the following diagram: the applet 1 is deleted and the new one loaded.

Applet2 "NEW"

State of the card

Applet2

The final model for the data structure includes the two concepts previously defined: The card architecture and the actions that have to be performed during the personalization.

This part of the personalization model would be used in order to easily navigate throw the card structure and retrieve, for each entity, the action that would be done.

NB: This “actions” concept is a high-level approach to describe the different card states, but it does not include the information for the APDU commands that have to be sent to the card. In other words, the actions are used to optimise the script generation but they have first to be interpreted in order to generate the real commands sequence (this aspect would be treated in details in the automatic process section).

Let’s consider the first example, based on a native card, and assume that the directory already contains an elementary file (with the ID equal to 303). This file has to be deleted and two new files (301 and 302) have to be created. The data structure of the application profile would be as follows:

<Entity type = “Root” action = “None”>

<Entity type = “DF” ID = “101” action = “None”>

<Entity type = “EF” ID = “303” action = “Delete“/> <Entity type = “EF” ID = “301” action = “Create”/> <Entity type = “EF” ID = “302” action = “Create “/> </Entity>

</Entity>

(NB: The aim of the previous example is only to show the combination of the architectural and source concepts. The entity attributes “type” and “ID” are only used to make it understandable.)

Thus, the actions logic is an important aspect of the card modelling because it makes the data structure dynamic and allows the definition of a personalization model at any step of the card life cycle.