Smart Card Personalization Server

The primary use for Global Platform Scripting, Profile and Messaging is to provide for a standardized data preparation and chip personalization environment. In such an environment, cards are looked at from a multi-application perspective. Each application on a card is represented by an application profile, which defines the general structure, data elements and one or more personalization scripts.

The scripting server provides for such a standardized personalization environment and due to it's embeddable nature, it can be seamlessly integrated into any personalization management software for local and remote card personalization or update.

To turn the scripting server into a personalization server, you will just need to load the personalization server code into a running instance:

curl http://localhost:8080/admin?restart
curl -T persoserver.js http://localhost:8080/admin

The loadserver batch file first resets the scripting environment and then loads the personalization server code. The curl program is used to post the script file onto the server using the HTTP protocol. In an embedded scenario, this will be done by the personalization management platform before running a new job.

Once the personalization server is running, you will need to post the required key profiles and application profiles. Profiles are stored in an in-memory registry on the server and are later referenced by actual personalization requests. Again HTTP is used to post these artifacts onto the server.

curl -T kp_single_des_1.xml http://localhost:8080/se/kp
curl -T kp_double_des.xml http://localhost:8080/se/kp
curl -T kp_triple_des.xml http://localhost:8080/se/kp
curl -T ap_test.xml http://localhost:8080/se/ap

At this point the server is fully configured and ready to accept personalization requests. Requests are posted as CardCustomization elements based on the Global Platform Messaging specification:

<?xml version="1.0" encoding="UTF-8"?>
    <ModuleIdentifierCode Identifier="ELECTRICAL">
        <CardConfiguration CollatorStatus="4">
            <CRN Number="2A01020304"/>
            <AID AID="D276000001" Order="1"/>
            <ProcessingStep Action="PERSONALIZE" Requirement="01">
                    <Data DataElement="SerialNo" Value="12345678"/>

The ModuleIdentifierCode element addresses the electrical personalization. The CardConfiguration element uniquely identifies the card to the personalized. The ApplicationData element contains the unique identification of the on card application that is going to be personalized. The ApplicationProfileUniqueID element identifies the application profile to use, ProcessingStep lists the sequence in which scripts in the profile are executed. ICCData contains the required data sets, which contain the data used by the personalization scripts.

The personalization request is again posted to the server using HTTP.

set RDR=OMNIKEY%%20CardMan%%205x21%%200
curl --data-binary @CardCustomizationRequest.xml http://localhost:8080/se/reader/%RDR%

First the script defines the reader to use for personalization. The reader name becomes part of the URL, providing the ability to address individual reader in a multi-reader setup. The reader name must be encoded in URL encoding as it contains white space.

The personalization server parses the request and decodes the data elements into an internal pool of data elements. Such elements are referred to using the[] array within the script.

Once all personalization scripts requested in the ProcessingSteps are executed, the resulting data is collected and prepared in a CardAuditTrail. The CardAuditTrail is returned as response to the HTTP request.