GP Card Customization Guide v1.0

GlobalPlatform
Card Customization Guide

Version 1.0
13 August 2002
Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this
information is governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly
prohibited.
08/13/2002 GlobalPlatform Card Customization Guide v1.0 ii
Table of Contents
1. INTRODUCTION .................................................................................................................................................6
1.1 SUMMARY ....................................................................................................................................................6
1.2 SCOPE ...........................................................................................................................................................6
1.3 AUDIENCE ....................................................................................................................................................7
1.4 NORMATIVE REFERENCES ............................................................................................................................8
1.4.1 List of References.................................................................................................................................8
1.4.2 GlobalPlatform Document Navigation..............................................................................................10
1.5 TERMINOLOGY AND DEFINITIONS ...............................................................................................................11
1.6 ABBREVIATIONS AND NOTATIONS ..............................................................................................................17
1.7 REVISIONS HISTORY ...................................................................................................................................18
2. OVERVIEW ........................................................................................................................................................19
2.1 APPLICATION CODE AND LOAD FILE PROFILE ............................................................................................20
2.2 APPLICATION PROFILE AND CUSTOMIZATION SCRIPTS ...............................................................................20
2.3 APPLICATION SPECIFIC KEYS .....................................................................................................................21
2.4 OTHER CUSTOMIZATION SCRIPTS ...............................................................................................................21
2.5 APPLICATION INSTALLATION OPTIONS .......................................................................................................22
2.6 EXTERNAL DATA REQUIREMENTS FOR APPLICATION PERSONALIZATION ..................................................22
2.7 SELECTABLE SMART CARDS AND CARD PROFILES .....................................................................................23
2.8 CARD ISSUER SUPPLIED OR MANAGED KEYS .............................................................................................23
2.9 SMART CARD MANAGEMENT SYSTEMS ......................................................................................................23
3. THE CARD CUSTOMIZATION PROCESS ...................................................................................................25
3.1 CARD CUSTOMIZATION AND CARD PERSONALIZATION ..............................................................................26
3.2 MAJOR CUSTOMIZATION COMPONENTS......................................................................................................26
3.2.1 XML Parser .......................................................................................................................................26
3.2.2 Card Configuration ...........................................................................................................................26
3.2.3 Conflict Check ...................................................................................................................................27
3.2.4 Interface.............................................................................................................................................27
3.2.5 Script Interpreter ...............................................................................................................................27
3.3 CARD CUSTOMIZATION PROCESSES ............................................................................................................28
3.3.1 Application Development...................................................................................................................30
3.3.2 Personalization Data Preparation ....................................................................................................33
3.3.3 Card Customization ...........................................................................................................................36
3.3.4 Customization Validation (or Verification) .......................................................................................39
3.3.5 Post Issuance Customization .............................................................................................................41
3.4 RESPONSIBILITIES .......................................................................................................................................43
3.4.1 Application Developer Responsibilities.............................................................................................43
3.4.2 Application Provider Responsibilities ...............................................................................................43
3.4.3 Card Issuer Responsibilities ..............................................................................................................43
3.4.4 Card Manufacturer Responsibilities..................................................................................................44
3.4.5 Application Loader Responsibilities..................................................................................................44
4. PROFILES AND CARD CUSTOMIZATION PROCESS..............................................................................45
4.1 APPLICATION PROFILES ..............................................................................................................................46
4.2 CARD PROFILES ..........................................................................................................................................46

prohibited.
08/13/2002 GlobalPlatform Card Customization Guide v1.0 iii
4.3 LOAD FILE PROFILES ..................................................................................................................................50

4.4 KEY PROFILES ............................................................................................................................................50
4.5 SMART CARD IDENTIFICATION USING CARD PROFILES ..............................................................................50
4.6 ROLE OF CONFLICT DETERMINATION .........................................................................................................52
4.7 CONFLICT DETERMINATION RULES AND PROFILES .....................................................................................52
4.8 USING CARD PROFILES TO TRACK UPDATES TO PERSONALIZED SMART CARDS ........................................54
5. SCRIPTING AND CARD CUSTOMIZATION PROCESS............................................................................55
5.1 SCRIPTS ASSOCIATED WITH PROFILES ........................................................................................................55
5.2 TYPES OF SCRIPTS USED IN CUSTOMIZATION .............................................................................................55
5.2.1 Minimum Scripts................................................................................................................................56
5.2.2 Supplementary Scripts .......................................................................................................................57
5.3 SUGGESTED USE OF LOAD/INSTALL SCRIPTS..............................................................................................58
5.4 SUGGESTED USE OF DATA PREPARATION SCRIPTS .....................................................................................62
5.5 SUGGESTED USE OF PERSONALIZATION SCRIPTS ........................................................................................67
A. INTEGRATED EXAMPLE OF PROFILES AND SCRIPTS UTILIZATION............................................72
A.1 THE ACTORS...............................................................................................................................................73
A.1.1 Card Manufacturer............................................................................................................................73
A.1.2 Chip Manufacturer ............................................................................................................................74
A.1.3 Application Developer 1 ....................................................................................................................74
A.1.4 Personalization Bureau .....................................................................................................................75
A.1.5 Post Issuance Service Provider .........................................................................................................76
A.1.6 Card Issuer and Application Owner..................................................................................................76
A.1.9 Application Provider .........................................................................................................................78
B. CARD RECOGNITION MECHANISM ..........................................................................................................79
B.1. GENERAL MECHANISM ...............................................................................................................................79
B.2. OBJECT IDENTIFIER FOR CARD RECOGNITION DATA ..................................................................................80
B.3 APPLICATION TAGS ....................................................................................................................................80
B.4 CONTENTS OF DATA OBJECTS ....................................................................................................................81
B.5 OBJECT IDENTIFIER ENCODING...................................................................................................................81
B.6 EXAMPLE OF THE CODING OF CARD DATA WITH CARD RECOGNITION DATA .............................................82

prohibited.
08/13/2002 GlobalPlatform Card Customization Guide v1.0 iv
List of Tables
Table 1-1: GP Normative References..........................................................................................................................8
Table 1-2: non GP Normative References.................................................................................................................10
Table 1-3: Terminology and Definitions ...................................................................................................................16
Table 1-4: Abbreviations and Notations....................................................................................................................18
Table 4-1 – Summary of Profiles ..............................................................................................................................45
Table 4-2 – Additional Conflict Determination Rules...............................................................................................53
Table 5-1 – Minimum Scripts for every Security Domain Application Profile.........................................................56
Table 5-2 – Minimum Scripts for Application Profile ..............................................................................................56
Table 5-3 – Supplementary Scripts ...........................................................................................................................57

prohibited.
08/13/2002 GlobalPlatform Card Customization Guide v1.0 v
List of Figures
Figure 3-1 – Logical Representation of Card Customization Processes....................................................................29
Figure 3-2 – Work Flow for Application Development ............................................................................................32
Figure 3-3 – Work Flow for Personalization Data Preparation.................................................................................34
Figure 3-4 – Work Flow for Pre-Issuance Card Customization ................................................................................38
Figure 3-5 – Work Flow for Customization Validation (or Verification) .................................................................40
Figure 3-6 – Work Flow for Post-Issuance Card Customization ..............................................................................42
Figure 4-1 – Relationship between Card Profile and Card without SCMS ...............................................................47
Figure 4-2 – Relationship between Card Profile and Cards with SCMS...................................................................47
Figure 4-3 – Examples of Using Tag EE and SCMS Fields......................................................................................49
Figure 4-4 – Smart Card Identification Using Card Profile ......................................................................................51
Figure 5-1 – Suggested GP Scripting Objects Available for Use by Load/Install Scripts ........................................59
Figure 5-2 – Minimum Profile and Script Components for Load/Install Script........................................................60
Figure 5-3 – Minimum Object Creation for Load/Install Script................................................................................61
Figure 5-4 –Suggested GP Scripting Objects Available for Use by Data Preparation Scripts..................................64
Figure 5-5 – Minimum Profile and Script Components for Data Preparation Script ................................................65
Figure 5-6 – Minimum Object Creation for Data Preparation Script ........................................................................66
Figure 5-7 –Suggested GP Scripting Objects Available for Use by Personalization Scripts ....................................69
Figure 5-8 – Minimum Profile and Script Components for Personalization Script...................................................70
Figure 5-9 – Minimum Object Creation for Personalization Script ..........................................................................71
Figure A- 1 – Examples of Interactions Using Profiles.............................................................................................72
Figure A- 2 - Smart Cards and GP Card Profile for ACME MegaCard 1.0.0...........................................................73
Figure A- 3 –Card and Card Profile for ACME MegaCard 1.0.0 with EasyChipPay...............................................74
Figure A- 4 – UniversalChip Supply Chip Information using a Partial Card Profile................................................74
Figure A- 5 – GP Application Profile for Bleinheim’s Security Domain Application..............................................75
Figure A- 6 – Profile and Script for Load/Install at the Personalization Bureau.......................................................75
Figure A- 7 – Four Personalized Smart Cards with One GP Card Profile ................................................................77
Figure A- 8 –Application Profile Created for EasyChipPay .....................................................................................78
Figure A- 9 – GP Load File Profile Created for EasyChipPay Application..............................................................78

prohibited.
08/13/2002 GlobalPlatform Card Customization Guide v1.0 6
1. Introduction
1.1 Summary
For smart card implementations, one of the key efforts facing card issuers is the processes involved in
transforming a basic smart card product to one that is personalized for an individual cardholder or customer.
For each application the issuer considers as part of their smart card offerings, time must be set aside to
understand the requirements for the application in order for the application to be successfully placed on a smart
card. These requirements include potential smart card dependencies, installation options for the application,
data requirements, and steps used to personalize the application onto the smart card. These requirements and
the resultant implementation effort are multiplied when multiple permutations are available for the
customization of an application.
Currently, for each of the requirements, the card issuer’s choice of vendor(s) for the relevant supporting
systems dictates the technology and processes to use to fulfill the requirement. Unfortunately, in the absence of
pervasive standards, this entails a proprietary approach. Furthermore, since card issuers will select the systems
which offer the best solution for their particular business requirements and existing technology infrastructure,
systems integration work between incompatible systems adds to the workload.
While with static card issuance, the systems integration work is a one time affair, the dynamic character of
multi-application issuance will impact the card issuer with each new application offered or issuer card product
marketed. GlobalPlatform, being a organizational vehicle to facilitate the adoption and propagation of multi-
application smart card implementations, has tasked itself with creating standards to help streamline the card
customization process and for inter-system integration. There are currently two specifications which help
standardize the card customization process, and the latter of these two specifications is also the first step to
setting the stage for inter-system integration. These two specifications are GlobalPlatform Systems Scripting
Language Specification 1.0 [GP_SYS_SCR] and GlobalPlatform Systems Profiles Specification 1.0
[GP_SYS_PRF]
1.2 Scope
The objectives of this document are:
• To describe the card customization process under GlobalPlatform;
• To describe the major customization components required to implement the card customization process
under GlobalPlatform;
• To define the responsibilities for each of the major roles involved in the card customization process
• To describe how GP profiles and the GP Scripting Language should be used for card customization
• To provide examples of potential card customization implementation scenarios.
Version 1.0 of this document focuses on using
• The GlobalPlatform Card Profiles, Application Profiles, Key Profiles, and Load File Profiles defined in
GlobalPlatform Systems Profiles Specification 1.0 [GP_SYS_PRF].

prohibited.
• The GP Scripting Language defined in the GlobalPlatform Systems Scripting Language Specification
1.0. [GP_SYS_SCR]
1.3 Audience
This document targets a broad audience, including business analysts, project managers, and systems integrators,
because it addresses the core methodology behind facilitating smart card customization in a GlobalPlatform
multi-application smart card implementation.
This document will be particularly useful to:
• Card manufacturers who will create profiles for their smart card products;
• Application developers who will create profiles and scripts for their applications;
• Actors involved in the architecture, design, and implementation of systems supporting card
customization tasks, including smart card software and hardware vendors, personalization bureaus,
application developers, card issuers, or parties providing services to any of these entities;
• Actors who need to utilize and modify profiles and scripts in order to complete card customization
objectives.

prohibited.
1.4 Normative References
1.4.1 List of References

Standard / Specification Description
[GP SYS_SCMS_REQ] describes the necessary
Multi Application Smart Card Management components for
Systems GlobalPlatform Functional effectively managing the life cycle of an Open Platform multi
Requirements v3.4 May 2001 application smart card and its related applications.
Available at http://www.globalplatform.org/
[GP SYS_SCMS_IMP] Provides a broad overview of the

GlobalPlatform A Primer to the Implementation processes involved in launching a multi application program
of Smart Card Management and Related and describes some of the initial services that issuers,
Systems v1.0, August 2000 vendors or system integrators may choose to implement.
Available at http://www.globalplatform.org/
[GP_SYS_CCG] Describe the major customization

components required to implement the card customization
GlobalPlatform Card Customization Guide v1.0 process, the responsibilities for each of the major roles and
how GP profiles and the GP Scripting Language should be
used for card customization under GlobalPlatform;
GlobalPlatform Card Specification 2.0.1’ [GP_CARD_CS] Defines the requirements for a

GlobalPlatform Card Specification 2.1 GlobalPlatform smart card.
GlobalPlatform Systems Scripting Language [GP_SYS_SCR] Defines the language to use to create code
Specification v1.0 to customize multi-application smart cards.
GlobalPlatform Systems Profiles Specification [GP_SYS_PRF] Basic XML data structures used to describe
v1.0 smart cards, applications, and related entities
Table 1-1: GP Normative References

prohibited.
Standard / Specification Remarks

Borenstein, N. and Freed, N., Internet
Engineering Task Force RFC 1521
Multipurpose Internet Mail Extensions (MIME)
[IETF_RFC1521] Defines the BASE64 format.
part One: Mechanisms for Specifying and
Describing the Format of Internet Message
Bodies, September 1993.
ECMAScript – 3rd Edition (ECMA 262

[ECMA 262]
Standard)
Extensible Markup Language (XML) 1.0, W3C

Recommendation 10-Feb-98, REC-xml- [W3C_XML]
19980210
ISO/IEC 7811-6: Identification cards --

Recording technique -- Part 6: Magnetic stripe [IS7811-6] Compact Numeric format defined.
-- High coercivity, 2001.
ISO/IEC 7816-3: Information Technology –

Identification Cards – Integrated Circuit(s)
Cards with Contacts – Part 3: Electronic [IS7816-3]
nd
Signals and Transmission Protocols, 2
Edition, 15 December 1997.
ISO/IEC 7816-4: Information Technology –

Identification Cards – Integrated Circuit(s)
Cards with Contacts – Part 4: Interindustry [IS7816-4]
st
Commands for Interchange, 1 Edition, 1
September 1995.
ISO/IEC 7816-5: Identification Cards –

Integrated Circuit(s) Cards with Contacts –
Part 5: Numbering System and Registration [IS7816-5]
st
Procedure for Application Identifier, 1 Edition,
15 June 1994
ISO/IEC 7816-6: Identification Cards –

Integrated Circuit(s) Cards with Contacts – [IS7816-6]
Part 6: Interindustry Data Elements, 1996
ISO 8825 - International Standard

Organization - Information Technology - ASN.1 [IS8825]
Encoding Rules – 1995
ISO 9797 – International Standard

[IS9797]
Organization
Go to the following web site for Multos™ documentation:

Multos card
http://www.multos.com/

prohibited.
Standard / Specification Remarks

PKCS #1 - RSA Laboratories - RSA Encryption
[PKCS#1]
Standard - Version 1.5 - November 1993
Rivest, R., Internet Engineering Task Force
RFC 132 - The MD5 Message-Digest
Algorithm, April 1992.
The UniCode Consortium, The Unicode
[UNICODE] Defines the UTF-8 format.
Standard - Version 3.2, March 2002.
Table 1-2: non GP Normative References
1.4.2 GlobalPlatform Document Navigation

The GlobalPlatform Card Customization Guide [CP_SYS_CCG] defines how multi-application smart cards can
be customized and managed using GlobalPlatform profiles and scripts. This document serves as a guideline only.
However, for interoperability purposes, the general methodology described in this guide needs to be adhered to;
• GlobalPlatform Profiles Specification [GP_SYS_PRF]: Defines the basic data structures in XML used
to describe smart cards, applications, and related entities. Participants will need to populate and
exchange GlobalPlatform profiles according to the methodology described in GlobalPlatform Card
Customization Guide [CP_SYS_CCG] to assure interoperability;
• GlobalPlatform Scripting Specification [GP_SYS_SCR] : Defines the language to use to create code
to customize multi-application smart cards. Makes explicit use of specific components inside several of
the GlobalPlatform profiles;

prohibited.
1.5 Terminology and Definitions

Term Definition
Actor Unique entity participating in an GlobalPlatform compliant smart card

environment. These entities can take forms such as card issuers,
application developers, and Personalization Bureaus
Application Developer Actor responsible for the development of Smart Card applications
Application Identifier Uniquely identifies an application in a smart card according to ISO 7816-5.
Instance of an Executable Module after it has been installed and made

Application Instance
selectable.
The Application Profile describes a smart card application, independent of

Application profile any particular smart card. It acts as a template for creating the actual
application.
Application Protocol Data Unit Standard communication messaging protocol between a card accepting
(APDU) device and a smart card
Entity that owns an application and is responsible for the application's

Application Provider
behavior
The link between the application and the external world during a Card
Application Session Session starting with the Application selection and ending with Application
de-selection or termination of the Card Session
The current life cycle state of an application on a GlobalPlatform smart

Application State
card.
A cryptographic technique that uses two related transformations, a public

transformation (defined by the Public Key component) and a private
Asymmetric Cryptography transformation (defined by the Private Key component); these two key
components have a property so that it is computationally infeasible to
discover the Private Key, even if given the Public Key
Code and Application information (but not Application data) contained in the
Card Content card that is under the responsibility of the OPEN e.g. Executable Load
Files, Application instances, etc
Card Customization
Card Image Number (CIN) An identifier for a specific OP card
Cardholder The end user of a card
Entity that owns the card and is ultimately responsible for the behavior of
Card Issuer
the card
Generic term for the 3 card management entities of an Open Platform card
Card Manager i.e. the Open Platform Environment, Issuer Security Domain and the
Cardholder Verification Method Services provider

prohibited.
Term Definition
Role that is responsible for producing (smart) cards on behalf of a Card
Issuer. What services are performed depend on its contractual relationship
(Smart) Card Manufacturer
with the Card Issuer and may include part or all of the card production
process.
Card personalization is defined in this document as the process of

producing a card customized to a specific cardholder and eventually
modifying its contents after issuance to add and delete functionality. In that
Card Personalization broad sense, Card Personalization starts as early as application software is
loaded onto a chip, ends temporarily with card issuance, and is re-enacted
as soon as a new application is added (or deleted) or when some on-card
data is updated post-issuance
Products are provided by card manufacturers. A product is an

Card Product implementation of an operating system on a chip; it is a card ‘model.’ Some
application instances may exist on a product (pre-loaded applications).
The Card Profile describes a smart card. This card could be a singularly
unique card or a card that shares common characteristics, as defined in the
Card Profile
Card Profile, with other cards. Depending on how it is used, it either acts as
a base template for a smart card or represents a single smart card by itself.
Information that tells an external system, in particular a Card and

Card Recognition Data Application Management System (CAMS), how to work with the card
(including indicating that this is an OP card)
The link between the card and the external world starting with the ATR and
Card Session
ending with a subsequent reset or a deactivation of the card
Data that uniquely identifies a card being the concatenation of the Issuer
Card Unique Data
Identification Number and Card Image Number
A DES encryption method where the results of the encryption of previous

blocks are fed back into the encryption of the current block; therefore each
Cipher Block Chaining
cipher text block is dependent not just on the plaintext block that generated
it but on all the previous plaintext blocks.
This has been replaced with the specification GlobalPlatform Systems

CCSB Scripting Language Specification 1.0 and GlobalPlatform Systems Profiles
Specification 1.0.
A corporation that manufactures processor chips used in Smart Cards and

Chip Manufacturer
Smart Card related form factor
A message sent by the host to the smart card that initiates an action and
Command
solicits a response from the smart card.
Description of the rules of compatibility between both Card and Application

Profiles as used by Card Configurator functionality, whether this
Conflict Determination Table
functionality resides within a Smart Card Management System or is resident
elsewhere
Cryptogram The result of a cryptographic operation.

prohibited.
Term Definition
DAP Block Part of the Load File used for ensuring Load File Data Block verification
Data Authentication Pattern Used to authenticate and/or verify the integrity of the data. This can be
(DAP) done using a DES key or Public key mechanism.
A Security Domain with a DAP Verification Privilege will perform the

DAP Verification Privilege
verification of the Load File Data Block DAP.
Data Encryption Standard

A symmetric cryptographic algorithm.
(DES)
The process of gathering and preparing the necessary application data and
Data Preparation keys for input into the personalization device. The process can be driven by
the Data Preparation Scripts provided in the Application Profile.
The reversal of the corresponding encryption, reversible transformation of a

Decryption cryptogram by cryptographic algorithm to retrieve the original plain text
data.
Delegated Management allows an Application Provider to load and install

Delegated Management an application on a card, with the Card Issuer still retaining control over the
content of the card.
Physical piece of hardware used in card Card Personalization, both pre-

Device
issuance and post-issuance or card acceptance scenarios
Device Manufacturer A corporation which manufacturers devices
Used to contain minimum device related content in order for a SCMS to

Device Profile
perform conflict determination
An asymmetric cryptographic transformation of data that allows the recipient

of the data to prove the origin and integrity of the data; it protects the
Digital Signature
sender and the recipient of the data against forgery by third parties; it also
protects the sender against forgery by the recipient
A DES encryption method where one block of plaintext always encrypts to

Electronic Code Book (ECB) the same block of cipher text; therefore each plaintext block is encrypted
independently (see also Cipher Block Chaining).
The reversible transformation of data by cryptographic algorithm to produce

Encryption
a cryptogram.
Actual on-card container of one or more application’s executable code

(Executable Modules). It may reside in immutable persistent memory or
Executable Load File
may be created in mutable persistent memory as the resulting image of a
Load File Data Block
Contains the on-card executable code of a single application present within

Executable Module
an Executable Load File
A logical term used to represent the back end systems that support the
Open Platform system; hosts perform functions such as authorization and
Host
authentication, administration, post-issuance application code and data
downloading, and transactional processing
prohibited.
Term Definition
Immutable Persistent Memory Memory that can only be read
Issuer Identification Number

The Issuer unique Identifier as defined in ISO 7812.
(IIN)
On-card entity providing support for the control, security, and

Issuer Security Domain
communication requirements of the card issuer
A sequence of bits that controls the operation of cryptographic

transformation. Keys are used in symmetric algorithms (secret keys, e.g.,
Key
DES) and asymmetric algorithms (public key and private key pair, e.g.,
RSA).
The Key Profile describes a cryptographic key, independent of any

Key Profile particular instance of the key. It acts as a template for creating the actual
key.
The existence of Card Content on an Open Platform card and the various
Life Cycle
stages of this existence where applicable
Life Cycle State A specific state within the Life Cycle of the card or of Card Content
A file transferred to an Open Platform card that contains a Load File Data
Load File
Block and possibly one or more DAP Blocks
Part of the Load File that contains one or more application(s) and libraries
Load File Data Block or support information for the application(s) as required by the specific
platform
Load File Data Block Hash A value providing integrity for the Load File Data Block
A value encompassing the Load File Data Block Hash and providing both
Load File Data Block Signature
integrity and authenticity of the Load File Data Block
One-way hash method to generate a 16 byte digital signature which is, in all
MD5
likelihood, unique
Mutable Persistent Memory Memory that can be modified
Open Platform Environment The central on-card administrator that owns the Open Platform Registry
Open Platform Registry A container of information related to Card Content management
A smart card operating system or run-time environment that provides a

consistent and hardware neutral execution environment for applications,
OS Platform
ensuring inter-operability and portability of applications across products
compliant to the same platform specification, independently of the product
supplier.
A corporation delegated by a card issuer the responsibility to manage and

Personalization Bureau
personalize smart cards for that card issuer

prohibited.
Term Definition
Scripts that are created by the scripting process and used for the Card
Personalization process. There are three types of scripts:
• Data Preparation Script (DPS),
• Card Creation Script (CCS),
Personalization Script
• Data Verification Script (DVS),
• And other scripts used for post-issuance personalization activities.
Each script will be unique for each personalization run
The script langage is defined in [GP_SYS_SCR]
Plain text Un-encrypted clear text information.
Post-Issuance Phase following the card being issued to the cardholder
Pre-Issuance Phase prior to the card being issued to the cardholder
Private Key The private component of the asymmetric key pair
Combination of a set of applications selected by an card issuer with a

selected smart card platform. The product Profile is represented by a
Product Profile combination of Application Profiles (an application portfolio) and a Card
Profile. A product Profile will, at a minimum, contain Application Profile(s)
and a Card Profile
Collection of information specific to SCMS needs. There are three types of

profiles defined; card, device, and application.
Profiles are a description of the information, data and processes required to
represent smart card platforms (Card Profiles) and chip applications
(Application Profiles) that are used during the Card Personalization process.
Specifically, profiles would contain grouping of Profile Elements, Data
Elements, Process Elements, and Script Fragments that describe card
Profile characteristics or application requirements, and required data and
processes required representing a Card or an Application. A Profile is used
for compatibility checks and personalization script generation. It must be a
self-sufficient grouping containing (or referencing) all definitions used by
any of its Elements and Script Fragments. Profiles for card and Application
Profiles are a subset of the information contained in the Profile
Profiles are defined in [GP_SYS_PRF]
Public key The public component of the asymmetric key pair
An asymmetric transformation of the public key by a certification authority

Public Key Certificate and intended to prove to the public key’s recipient the origin and integrity of
the public key. It also contains information about the owner of the key.

prohibited.
Term Definition
Functionality which may be resident in an singular application or
Smart Card Management incorporated into existing card management systems that provides facilities
System (SCMS) for supporting the administration, personalization, and issuance of smart
cards
Interfaces between a Smart Card Management System and

SCMS Interface systems/applications resident at the same actor or at different actors. The
interfaces will be used to transport Profile dat
A communication mechanism between an off-card entity and a card that

Secure Channel
provides a level of assurance, to one or both entities
A session, during an application session, starting with the Secure Channel

Secure Channel Session Initiation and ending with a Secure Channel Termination or termination of
either the application session or card session
On-card entity providing support for the control, security, and

Security Domain
communication requirements of the application provider
Functionality which may be resident in an singular application or

Smart Card Management incorporated into existing card management systems that provides facilities
System (SCMS) for supporting the administration, personalization, and issuance of smart
cards.
A cryptographic technique that uses the same secret key for both the
Symmetric Cryptography
originator's and the recipient's transformation
A mechanism from which the Card Manager on a card can determine

Token whether or not pre-approval / pre-authorization from the Card Issuer was
given to perform a given function.
Either in a Card Profile or a Card Profile format which contains information

regarding specific applications for a cardholder or set of cardholders. The
updated Card Profile is a concept used to represent smart cards that have
Updated Card Profile
been issued. Updated Card Profiles may need to be managed on an
individual cardholder basis depending on the extent to which personalized
cards are unique
XML document A file containing XML-formatted information.
Table 1-3: Terminology and Definitions

prohibited.
1.6 Abbreviations and Notations

Abbreviation Meaning
AID Application Identifier
APDU Application Protocol Data Unit
ASN1 Abstract Syntax Notation 1 (see [IS8825])

ATR Answer-to-Reset
BER Basic Encoding Rules
CIN Card Image Number / Card Identification Number
CLA Class Byte of the Command Message
CVM Cardholder Verification Method
DAP Data Authentication Pattern
DES Data Encryption Standard
EMV Europay, MasterCard, and Visa; used to refer to the ICC Specifications for Payment Systems
FCI File Control Information
IC Integrated Circuit
ICC Integrated Circuit Card
IIN Issuer Identification Number
INS Instruction Byte of Command Message
ISO International Organization for Standardization
Lc Exact Length of Data in a Case 3 or Case 4 Command
Le Maximum Length of Data Expected in Response to a Case 2 or Case 4 Command
LV Length Value
MAC Message Authentication Code
OID Object Identifier specified by ASN1.
OPEN Open Platform Environment
P1 Parameter 1
P2 Parameter 2
P3 Parameter 3
PIN Personal Identification Number
RAM Random Access Memory
RFU Reserved for Future Use
RID Registered Application Provider Identifier

prohibited.
Abbreviation Meaning
ROM Read-only Memory
RSA Rivest / Shamir / Adleman asymmetric algorithm
SCMS Smart Card Management System
SW Status Word
SW1 Status Word One
SW2 Status Word Two
TLV Tag Length Value
XML Extensive Markup Language
Table 1-4: Abbreviations and Notations
1.7 Revisions History

prohibited.
2. Overview
This section provides a high level synopsis of how GlobalPlatform Systems Scripting Language Specification
1.0 [GP_SYS_SCR] and GlobalPlatform Systems Profiles Specification 1.0 [GP_SYS_PRF] can be used to
standardize the card customization process. At the most simplest level, the first specification defines a
language to use to write individual scripts for discrete card customization tasks, and the second specification
defines a data interchange format for applications, cards, keys and load files. Together, the GP Scripting
Language and the profiles form a standardized and powerful toolset for the modification of smart cards in every
step of the card customization process, from initial card enablement to the final decommissioning of an issued
smart card.
After understanding this overview, the reader can delve into Section 3 – The Card Customization Process and
reference the two technical documents GlobalPlatform Systems Scripting Language Specification 1.0 and
GlobalPlatform Systems Profiles Specification 1.0 as required. The end goal of this process is to fully
understand how to create and employ profiles and scripts to enable card customization.
The role of scripts and profiles is best appreciated by understanding the roles and responsibilities which can be
undertaken by the actors, and correspondingly, the actors’ systems, in a multi-application smart card
implementation. In the CAMS model defined in [GP SYS_SCMS_REQ], a card issuer will receive an
application from an application provider, who secures the application from an application owner, who in turn,
resorts to an application developer to develop and maintain the application. From the perspective of card
customization, the application developer is the originator of:
• The application code packaged in a load file, and a corresponding Load File Profile for the load file.
• An Application Profile for the application, which includes scripts for how to prepare data for each
different type of installation for their application, and finally, the smart card commands required to
personalize their application onto a smart card.
• Application specific keys required for the preparation of data and the personalization of the application,
along with the corresponding Key Profiles.
• Optional scripts for other customization functions such as post issuance data preparation or
personalization.
• A document summarizing the installation options available for their application, and the resultant
parameters and external data required by the scripts, including parameters to pass to a security domain’s
load and/or install scripts.
After the applications for an issuer’s smart card offering are determined, the card issuer controls:
• The viable smart cards for the application portfolio selected, along with the corresponding Card Profiles.
• Card issuer controlled keys required for the personalization of applications.
• Smart Card Management services to manage smart card offerings.
Profiles are required to both initiate and complete the card customization process. For both card configuration
purposes and card production purposes, the larger role of profiles is to provide enough informational and
process instructions to successfully determine whether a portfolio of applications is viable on a selected smart
card platform, and subsequently supply the instructions required to customize the card.

prohibited.
In concert with the GP Scripting Language defined in GlobalPlatform Systems Scripting Language
Specification 1.0 [GP_SYS_SCR], which offers an open and flexible language for the representation of these
instructions, the ensuing GlobalPlatform card customization architecture offers a solution for each of the
components described above.
2.1 Application Code and Load File Profile

The application code will depend on the development platform used for developing the application, such as
JavaCard, Windows for Smart Cards, or MULTOS. It is expected that regardless of the development
environment, there will be a load file which can be loaded and installed onto a GlobalPlatform card.
The Load File Profile described in GlobalPlatform Systems Profile Specification 1.0 [GP_SYS_PRF]defines a
structure and format used to communicate information about load files. Included inside this profile is
information about individual application modules, application identifiers, and load file names. Load File
Profiles, like other profiles, are uniquely identified by an attribute which identifies the owner of the Load File
Profile and uniquely distinguishes the profile amongst the owner’s other Load File Profiles.
In card customization, when load files are transported between systems, the Load File Profile should be
transported as well. By accepting Load File Profiles, systems can decipher what is contained within a load file
and also use pertinent information, such as load file name and application identifier(s), to supply to load and
install scripts.
2.2 Application Profile and Customization Scripts

Each application has requirements which need to be satisfied prior to the application being succesfully
customized onto a smart card. These requirements include smart card memory requirements, inter-application
dependencies, and data and key needs.
The Application Profile described in GlobalPlatform Systems Profile Specification 1.0 [GP_SYS_PRF]defines
a structure and format used to communicate information about applications. Included inside Application
Profiles are these requirements as well as the scripts written according to the GP Scripting Language defined in
GlobalPlatform Systems Scripting Language Specification 1.0 [GP_SYS_SCR]
In card customization, when card customization information, such as a request for data preparation or
personalization, are transported between systems, the Application Profile should be transported as well. By
accepting Application Profiles, systems can ascertain whether the application requirements are satisfied before
attempting a card customization task defined in a script. Application Profiles, like other profiles, are uniquely
identified by an attribute which identifies the owner of the Application Profile and uniquely distinguishes the
profile amongst the owner’s other Application Profiles.
For the scripts which are required for every application, namely data preparation and personalization,
standardized script names are suggested in this document. By encouraging the usage of the same script name
for the data preparation and personalization script, there will be less ambiguity about these common scripts
between applications.

prohibited.
2.3 Application Specific Keys

When creating personalization data or personalizing their application, an application developer may employ the
use of cryptographic functionality. While certain aspects of cryptographic usage are dictated by the platform
choice, such as the recommended approach to using platform keys in GlobalPlatform cards, the application
developer may choose to generate and utilize keys specific to the customization of their application onto a
smart card.
The Key Profile described in GlobalPlatform Systems Profile Specification 1.0 defines a structure and format
used to communicate information about keys. The Key Profile is both used for application specified keys and
keys provided and/or managed by the card issuer. The Key Profile acts as a template describing the
characteristics of a key and how the key may be used. Key Profiles, like other profiles, are uniquely identified
by an attribute which identifies the owner of the Key Profile and uniquely distinguishes the profile amongst the
owner’s other Key Profiles.
The implementation of an interpreter for the GP Scripting Language will, in its interfaces with Key
Management Systems (KMS) or cryptographic devices, enforce the template characteristics and rules. In card
customization, when keys are exchanged between systems, the Key Profile should be used as the reference
point. By accepting Key Profiles, systems which are not classified as KMS or cryptographic device can
detemrine whether the required keys are available prior to commencing execution of a script for a card
customization task.
2.4 Other Customization Scripts

The GP Scripting Language defined in [GP_SYS_SCR] can be used to defined scripts in the Application
Profile useful for a whole host of discrete post-issuance customization tasks. Examples of these tasks may
include adding application features in post-issuance, modifying on-card application data, blocking an
application, and loading an application. As well, tasks which are performed in pre-issuance such as loading
and/or installing the application, preparing the data for personalization, and personalization of the application
can also be done in a similar manner in post-issuance. In this latter case, for example, a card issuer may opt to
not include an application on their standard smart card offering, but allow the cardholder the opportunity to
download and personalize the application at a later date from a post-issuance device.
Post-issuance scripts are constructed in exactly the same way as pre-issuance scripts. Due to the varied nature
of post-issuance scripts, the names assigned to the scripts will not necessarily follow a prescribed guideline.

prohibited.
2.5 Application Installation Options

Application installation options can affect the customization of an application onto a smart card at every step of
the process. The application developer should document the various options as well as the data requirements
for their application, and then use the GP Scripting Language and profiles to implement them.
The GP Scripting Language has the capability to access parameters supplied by external systems using the
implicit linkage with data elements defined in the corresponding Application Profile. In this way, the
application developer can develop a single set of scripts which can handle each permutation of the application
installation.
As well, specialized applications, such as those for GlobalPlatform security domains, can also use external
parameters to drive application-independent scripts. For example, since application load and install operations
are performed under security domains for GlobalPlatform cards, the required parameters, such as the name of
the load file, application identifier and install parameters can be provided by means of external parameters to
the script. Therefore, the application developer for the security domain does not need to be aware of the target
application when constructing a load and/or install script.
For example, consider the application Sample which has two features Points and PIN, the latter of these two
features which is optional when customizing the application. If the PIN feature is selected, different install
parameters are required, data preparation is different, and personalization is different from the case were just
the Points feature is selected. For this application, the application developer specifies or creates:
• Two choices of installation parameters to be used with a security domain’s load and/or install script
• One script for the purposes of creating the data required by the application during personalization (data
preparation script). In the Application Profile, a parameter is used to specify whether the PIN feature
has been selected, and in turn, the data preparation script checks this parameter and creates the data for
the PIN feature if required.
• One script for the purposes of personalizing the smart card with the Sample application (personalization
script). Again, the same parameter defined for the data preparation script can be used in the
personalization script to check whether the PIN feature has been selected and to execute the necessary
smart card commands.
2.6 External Data Requirements for Application Personalization

Each application developer can specify their data requirements for personalizing their application. When this
data is unique per cardholder, this data is supplied by either or both of the card issuer and application provider.
The application developer should document the various options as well as the data requirements for their
application, and then use the GP Scripting Language and profiles to implement them.
The GP Scripting Language has the capability to access external data using the implicit linkage with data
elements defined in the corresponding Application Profile. In this way, the application developer can develop a
single set of scripts which can handle each permutation of the application installation.
Both parameters and external data use the same mechanism in the Application Profile and the GP Scripting
Language. From the GP Scripting Language perspective, supplied parameters and external data are both
viewed as data elements.

prohibited.
2.7 Selectable Smart Cards and Card Profiles

While the application developer will produce scripts and profiles for their application, keys, and load files, the
responsibility for defining which cards can be used as target smart cards for customizing the application rests
with the card issuer. Hence, the card issuer defines business rules for each smart card offering in terms of
which are acceptable smart card products to use for each application portfolio.
The Card Profile described in GlobalPlatform Systems Profile Specification 1.0 [GP_SYS_PRF] defines a
structure and format used to communicate information about smart cards. Included inside Card Profiles are
platform information, operating system information, memory available, and other features and capabilities of
the smart card product. The Card Profile also defines a means for describing both technical and business rules.
For each acceptable smart card product chosen, the card issuer needs to have the Card Profile. The originator
of the Card Profile is the manufacturer of the smart card product, but the card issuer will own any subsequent
card issuer dictated revisions to the Card Profile.
2.8 Card Issuer Supplied or Managed Keys

Aspects of cryptographic usage are dictated by the platform choice. For GlobalPlatform cards, this results in a
recommended approach to deriving and using platform keys in GlobalPlatform cards. Depending on the
application, the application developer may choose to utilize keys which will be supplied or managed by the card
issuer.
The Key Profile described in GlobalPlatform Systems Profile Specification 1.0 [GP_SYS_PRF] defines a
structure and format used to communicate information about keys. The Key Profile is both used for application
specified keys and keys provided and/or managed by the card issuer. The Key Profile acts as a template
describing the characteristics of a key and how the key may be used. Key Profiles, like other profiles, are
uniquely identified by an attribute which identifies the owner of the Key Profile and uniquely distinguishes the
profile amongst the owner’s other Key Profiles.
Therefore, the application developer will need to know the keys which will be supplied by a party other than
themselves. Since the application developer will not precisely be aware of the key profiles which map to these
keys, the responsibility may lie with the application provider to ensure that the key profiles are correctly
defined in the Application Profile for the application so that when the script is executed, the correct keys are
utilized.
The implementation of an interpreter for the GP Scripting Language will, in its interfaces with Key
Management Systems (KMS) or cryptographic devices, enforce the template characteristics and rules. In card
customization, when keys are exchanged between systems, the Key Profile should be used as the reference
point. By accepting Key Profiles, systems which are not classified as KMS or cryptographic device can
detemrine whether the required keys are available prior to commencing execution of a script for a card
customization task.
2.9 Smart Card Management Systems

In GlobalPlatform smart card infrastructures, the system which plays a key role in facilitating and managing the
full card customization lifecycle, including loading, installing, and personalizing applications onto selected
smart card platforms is termed a Smart Card Management System (SCMS). A Smart Card Management System
(SCMS) defines either a centralized or distributed software application, which contains functional components
necessary for the management of a GlobalPlatform multi-application smart card throughout its life cycle.
The following GlobalPlatform documents define the role of the SCMS in greater detail (see section 1.4

prohibited.
Normative References):
• Multi Application Smart Card Management Systems GlobalPlatform Functional Requirements;
• GlobalPlatform Smart Card Management Systems Implementation Guide.
Essential information concerning the selected smart card platform, less formally referred to as the card or smart
card, and the desired application portfolio must continually be interchanged with systems performing data
preparation, personalization, and post-issuance functionality. SCMS will help determine whether a selected
application portfolio and smart card platform is compatible, and whether the intended personalization device
can support the physical personalization requirements, requiring that this data be provisioned to these systems
through agreed upon interfaces and formats. This information, or content, will be provided in the form of
separate collections of data termed GlobalPlatform Profiles for cards, applications, keys, and load files.
It’s also important to distinguish between GlobalPlatform profiles and the messages that will be eventually
transported between the different systems in a GlobalPlatform Smart Card implementation. The profiles as they
are described in GlobalPlatform Systems Profiles Specification 1.0 [GP_SYS_PRF]and the scripts as they are
described in GlobalPlatform Systems Scripting Language Specification 1.0 [GP_SYS_SCR]represent the
format to be used when exchanging them. However, the GlobalPlatform Profiles and Scripts as they are
described in this document may be a component of a message being exchanged between systems. Therefore, in
the future, the GlobalPlatform profiles and scripts as they exist today may be a component of a standardized
message, such as in the response to a request for profile message. For the time being, it is suggested that the
implementer package the profiles and scripts in a manner seen as most suitable for their particular
implementation.

prohibited.
3. The Card Customization Process

The production process of a multi-application smart card requires multiple steps. These steps are listed here in
a logical order, while actual production process may follow other sequences:
• Developing the application(s) software;
• Configuring the multi-application smart card;
• Creating the chip itself (also called “masking”);
• Creating the plastic and embedding the chip;
• Preparing the smart card’s platform (card enablement);
• Loading application(s) software if necessary;
• Preparing the personalization data for each application;
• Adding personalization data (including sensitive data such as PIN and keys) to the applications;
• Validating the personalization.
A GlobalPlatform smart card possesses several characteristics, which enable it to be used in a dynamic
application development, issuance, and customization environment.
• First, GlobalPlatform smart cards allow for the separate development of applications, independently
from the underlying platform provided by individual card manufacturers;
• Second, a GlobalPlatform smart card allows independent development between each of the applications
that are coexisting on the same card and are provided by separate application developers;
• Third, a GlobalPlatform smart card also allows independent customization processes for each of the
applications that are coexisting on the same card;
• Finally, a GlobalPlatform smart card allows applications to be personalized at any time during the card
life cycle. Personalization security requirements would vary from one card life cycle stage to another.
The initial step in the GlobalPlatform card personalization process is the creation and supply of GlobalPlatform
profiles for cards and applications (see GlobalPlatform Systems Profiles Specification 1.0 [GP_SYS_PRF]).
An available set of “components” (applications and smart card platform) is provided to the SCMS or system
with card configuration capabilities by one or multiple entities such as application providers and card
manufacturers. The multi-application smart card is then configured with a particular application portfolio,
either in a pre-issuance or post-issuance scenario, from these components. Selections from the script library
contained within each of the Application Profiles are made and executed based on the desired target state of the
multi-application smart card. The sequencing of scripts for each application is informed by data provided in the
Application Profile, whereas the sequencing of scripts for a group of applications in an application portfolio
will depend on rules provided by the SCMS or the system assigned the task of sequencing the personalization
scripts for execution at a Personalization Device or post-issuance server, for example.
Scripts can be categorized as either:
• Scripts used for Data Preparation;
• Scripts used for initial card issuance (pre-issuance), including load/install and personalization scripts;
• Scripts used for post-issuance, including any of the two above categories of scripts;

prohibited.
• Scripts used for verification.

Pre-issuance and post-issuance scripts may include activities such as application code load, installation,
initialization, personalization, blocking, etc.
The GP scripting langage is defined in [GP_SYS_SCR]
3.1 Card Customization and Card Personalization

Originally, the terminology in use centered around the phrases card personalization or personalization of a card.
From a business perspective, this was sufficient in conveying the effect of a card issuer modifying a standard
issued card for a particular cardholder. However, the use of the term personalization causes confusion amongst
more technical minded audiences as personalization represents a very specific stage in the lifecycle of an
application. This latter use of the term often excluded the other processes that occurred while modifying a card
for a particular cardholder or group of cardholders, including card enablement, loading/installing of the
application code, and preparing the data to be used in personalization.
The term card customization is used to represent all these processes, and is synonymous with the business usage
of the term personalization. Furthermore, in this document, the usage of "card personalization" or
"personalization" refer to the technical interpretation of the term personalization.
3.2 Major Customization Components

The diagram in Figure 3-1 illustrates the generalized workflow for the card customization Process. There are a
number of key functionalities encapsulated into several components, many of which reside within the SCMS,
but which also can reside at Data Preparation systems, card customization systems, Validation systems, and
post issuance systems. The presence of a component would depend on what degree of functionality is
implemented at the system as well as how the system will interact with other systems. For example, a vendor’s
post issuance system which works exclusively with that same vendor’s SCMS will not require card
configuration or conflict check components since these would be done at the SCMS system. On the other hand,
for example, if a SCMS system simply passes the profiles and scripting information to a Personalization
Bureau, the system at the Personalization Bureau, whether it be in a personalization device or in a front end
SCMS-like system, must perform the functions not done at the originating SCMS.
In summary, regardless of where the component is implemented, each of the customization components must be
implemented at least once in order for the process flow described in Figure 3-1 to be completed.
3.2.1 XML Parser

The XML Parser has two primary responsibilities:
• Parsing the profile for Card Configuration purposes;
• Interfacing with the Script Interpreter to create required GP Scripting Language objects from the profile
3.2.2 Card Configuration

Card Configuration includes the following tasks:
• Selecting a product to personalize;
• Ensuring required Card Profile, Application Profile(s), and Load File Profiles are available;
• Performing a Conflict Check on the product configuration.
prohibited.
3.2.3 Conflict Check

The Conflict Check is responsible for ensuring that a product configuration is realizable:
• Ensuring that the Card Profile is compatible with all the Application Profile(s) using the conflict rules
defined in each;
• Ensuring that the Application Profile(s) are compatible with each other using the conflict rules defined
in each of them;
• Ensuring that all business and technical rules defined by the system implementing the conflict check
have been successfully passed.
Do not presume that conflict determination occurs within the purview of the SCMS only, nor assume that it is a
process monopolized by the system executing scripts. The conflict determination process will be the same
regardless of where it is performed, and hence, requires the same information as provided by profiles. For
example, information in the profiles will be required if additional applications are added after a conflict
determination table is created by the SCMS. Specifically, the SCMS may not be cognizant of what happens
further down the card personalization workflow or in post-issuance related card personalization, but these
activities require that conflict determination be performed before cards are personalized again.
3.2.4 Interface
The Interface component has responsibility for interfacing with other systems in order to exchange profiles and
scripts and support future standardized GlobalPlatform Messages defined in [GP_SYS_MSG]
3.2.5 Script Interpreter

The Script Interpreter has the following primary responsibilities:
• Executing the script;
• Generating the required profile objects in JavaScript as necessary from the profile;
• Provide a data mapping function so all data elements required are available;
• Provide an interface to a key management system so all keys required are available;
• Keeping track of script execution and updating/generating data;
• Generating required data elements and key objects from the profile.

prohibited.
3.3 Card Customization Processes

This section provides an overview of the card customization processes and the intended purpose of scripting
and profiles in the process. It describes different potential scenarios where scripts can be utilized.
Figure 3-1 illustrates the major steps of the multi-application smart card production process and illustrates the
position of the profiles and scripts within the production flow. This can be related to the CAMS working model
defined in [GP SYS_SCMS_REQ]
For each of the systems, either a subset or the entire customization product flow could occur. It is not
necessarily true that each card Profile only represents a single card in the production flow. This determination
is left up to implementation considerations, and for the SCMS to manage.

prohibited.
GP Application Profile +
Application GP Load File Profile
Development
GP Script
GP Card Profile
Card Interpreter
Manufacturer
GP Device Profile
(Future) Personalization
Device
Manufacturer Data
Data Prep. Preparation External
XML Parser
Updated GP Card Configuration Script Data
Card Profile1
and/or Specific SCMS Perso. Data File
Card Information2 (i.e., P3 file)
Interface
Card Creation
Script
Profiles
Updated GP Card
GP Application Profile +
Card Profile1 Personalization
GP Load File Profile Personalized
and/or Specific Smart Cards
Card Information2 GP Card Profile
Data Verification
Script
Personalization
Validation Personalized
Card Customization Smart Cards
Messaging3
Application
Specific Scripts
Post Issuance
Personalization
Personalized
Smart Cards
Figure 3-1 – Logical Representation of Card Customization Processes
NOTES:
1. If the Card Profile Unique ID is updated as a result of a card customization activity, then the information
needs to be returned to the SCMS.
2. If the Card Profile associated with the card contains SCMS specific fields that uniquely identify a smart
card, then this information needs to be returned to the SCMS.
3. Card customization messaging represents the interchange of card customization related messages
between system entities in a GlobalPlatform smart card Systems Infrastructure. Several of these
messages are specified in GlobalPlatform work to date. However, a consistent and integrated messaging
infrastructure is the objective going forward. This will be reflected in the GlobalPlatform Messaging
Specification v1.0 under Development [GP_SYS_MSG]

prohibited.
3.3.1 Application Development

The role of the application developer is to develop chip-based applications. This section identifies the
functions of this system, which are necessary for successful completion of the application customization
process. Figure 3-2 provides a high level overview of the role of the Application Profile and the application
development lifecycle.
The application specification phase defines the application’s features including the application specific
customization features. An application provider creates the application specification.
The application development phase is based on the application specification. A third party software
development company may act as an application developer as well as a card manufacturer, which typically
develops application software that will be burned, or masked, directly into the chip’s ROM. The application
development effort depends on the programming language supported by the target platform. For example, Java
for Java Card or Visual Basic for Windows for Smart Cards are some programming languages that could be
supported. The application developer creates the application software code (which is, for instance, “converted”
into a CAP file for a Java Card platform). See section 1.4

prohibited.
Normative References for further details.

The application developer also needs to create the Application Profile thoroughly describing the application as
required by the GlobalPlatform Systems Profiles Specification 1.0[GP_SYS_PRF] and also to create the scripts
needed to prepare data, load and personalize the application onto a target chip platform. As well, the
application developer may also supply scripts to be used for conceivable post-issuance operations with their
application.
Any external data or parameters required by the script are defined as data elements in the Application Profile.
Likewise, any keys will be defined as keys in the Application Profile. The Application Profile also allows a
declaration of data elements and keys used for specific scripts. The transformation of these keys and data
elements into objects in the scripting environment is described in the GlobalPlatform Systems Scripting
Language Specification 1.0. [GP_SYS_SCR]
The term application developer has been used to denote the role responsible for developing the application.
Whether or not this role is handled by the actor who performs the role of application provider, a role known as
the Application Provider will provide the application code, documentation, the Application Profile and the
scripts.

prohibited.
Test Smart
Card
Application Application Application

Specification Development Test/Verification
Application Application Provider
Code Signing Keys
GP Application
XML JS
Profile
Signed Application
GP Scripts Code
XML
GP Load File Profile
Figure 3-2 – Work Flow for Application Development

prohibited.
3.3.2 Personalization Data Preparation

The purpose of personalization data preparation is to generate a personalization data file for a batch of smart
cards. The personalization data file which is generated by the data preparation script has a format specified by
the application developer. The application developer will create a corresponding personalization script (card
creation script) to personalize their application onto a smart card using the data in the personalization data file
created.
It is important to note that the data preparation script create is a general purpose script used to create the
personalization data file for any set of cardholder data and parameters supplied. Therefore, the script will not
use specific values unless these values are constant for each cardholder and across all implementations of the
application. Instead, the data preparation script will use external data and parameter references defined using
data elements in the Application Profile, and which will be mapped to the supplied input files (i.e., cardholder
data file and personalization parameter file) upon execution of the script at the data preparation system.
This section identifies data preparation functions that are necessary to the customization process. The data
preparation system will implement the following card customization components:
• Interface to receive profiles, usually but not limited to Application Profiles and Key Profiles.
• XML parser to interpret and parse the Application Profile to determine which Key Profiles are required,
data elements which need to be present in the cardholder data file, parameters which need to be present
in the personalization parameters file, and the data preparation script to execute.
• XML parser to interpret and parse the Key Profiles.
• Interface to facilitate key exchange and cryptographic service requests.
• Script interpreter implementing GP Scripting Language support in order to prepare the necessary
scripting objects, including external data and keys, data mapping to supplied cardholder data file and
personalization parameter files, and finally, to execute the data preparation script to create the
personalization data file.
Figure 3-3 provides a high level overview of the role of the Application Profile and the Personalization Data
Preparation.

prohibited.
Application
Provider
Certificate
Authority
Either an issuer or
application provider
managed database.
Application/Issuer
Database System
Certificates
Cardholder Personalization Personalization

Data File Data Preparation Data File
Personalization Data Mapping

Parameters File
GP Script
Interpreter Data mapping will use
XML data element
Application XML Parser information in the profile to
Keys map data into the final
personalization data file
GP Application
JS
Profile(s)
Data Prep
Script
Conflict Check
Card
Configuration
SCMS
Figure 3-3 – Work Flow for Personalization Data Preparation

prohibited.
The inputs to a data preparation system are:

• A script used for data preparation (data preparation script);
• Personalization parameters, keys, and cardholder data needed to personalize the application per
cardholder.
Personalization data preparation generates a personalization data file for a batch of smart cards by executing the
instructions of the script used for data preparation (data preparation script), which populate an individual card
record (one record per card) with data based on the batch personalization parameters and unique cardholder
data. Both the personalization parameters and cardholder data need to be supplied by the card issuer (or
application provider) for a particular batch. The application developer, when creating the data preparation
script, will need to document what parameters, keys, and data are necessary in the Application Profile and will
need to write a script utilizing variables documented as data elements and keys in this Application Profile.
The data preparation script should not rely on knowledge of the target smart cards in order for the script to truly
work in a multi-application smart card environment since data preparation will likely occur independent of
smart card selection. Of course, there may be some smart card dependencies, such as those specified by the
platform and operating system implemented on the smart card. These dependencies are resolved in the conflict
determination process between the card and application profiles which needs to be performed prior to executing
personalization or card creation scripts.
In addition, the script may include some invocation of cryptographic methods such as generating card unique
keys or card unique public key certificates. In the example illustrated in the diagram, the card issuer (or the
application provider) provides the application (master) keys used by these cryptographic instructions.
The data preparation script utilizes generic references to data elements and keys as defined in the Application
Profile. These references need to be interpreted by a system performing personalization data preparation in
order to:
• Perform the required instructions of the data preparation script, such as generating chip data from
magnetic stripe data supplied in the cardholder data file, deriving card unique keys, and computing card
unique public key certificates;
• Locate (and use) the cryptographic keys: examples include a “master” DES key for deriving card unique
keys or an application provider RSA private key for signing card data;
• Import the actual data values defined in:
√ A card issuer (or application provider) parameters file containing the data values common or
generic to a specific batch of cards: examples include a key version identifier (common data with
the same value for each card in a batch) or a card number (generic data of a batch, incremented for
each card, but independent of any specific cardholder);
√ The card issuer (or application provider) personalization cardholder data file containing the data
values unique to each cardholder: examples include a cardholder name or PAN;
√ Optional card issuer (or application provider) public key certificates signed by the application
provider Certification Authority (CA).
The actual data mapping is specific to each personalization parameters and cardholder data files format and
each Data Preparation system. This is the implementation dependent component of smart card customization
since there is no way to know from an application developer standpoint the name of parameters, keys, and data
used in actual implementations.

prohibited.
3.3.3 Card Customization

The card customization system’s purpose is to customize a batch of smart cards, which includes the standard
loading, installing, initializing, and personalization phases associated with GlobalPlatform smart cards. The
scripts associated with these phases can be referred to as card creation scripts. A logical illustration of the card
customization system and its interfaces is provided in Figure 3-4.
This section identifies card customization functions required for the card customization system to work with the
GlobalPlatform card customization methodology. In industry, card customization systems are frequently
referred to as card personalization, or simply, personalization systems, and can also include post-issuance
servers or post-issuance devices
The personalization system will implement the following card customization components:
• Interface to receive profiles.
• XML parser to interpret and parse the Card Profile, and the Application Profile to determine which Key
Profiles are required, data elements which need to be mapped to the personalization data file and
supplied static data files, and the personalization or card creation script to execute.
scripting objects, including external data and keys, data mapping to supplied personalization data file
and static data files, and finally, to execute the personalization or card creation script to customize the
application onto the smart card.
The inputs to the card customization system are:
• Personalization data file created by a data preparation system executing the data preparation script for
the application;
• Scripts used to customize a card in pre-issuance (specifically load, install and personalization);
• Personalization keys, data, and the smart cards ready for production.
The outputs to the card customization system are smart cards that are then delivered to the card issuer’s
cardholders. As well, the card customization system must update the SCMS with information concerning
whether the customization operation was successful or not.
The card customization system personalizes a batch of smart cards by executing the instructions of the load,
install, and personalization scripts in that order. The load and install scripts are executed under the Security
Domain application specified for the smart card, and the personalization script is responsible for loading the
individual card and cardholder data contained in the personalization data file for each card of the batch. The
personalization data file contains one record per smart card to personalize and is itself produced by the Data
Preparation system.
For GlobalPlatform cards, the scripts used for pre-issuance customization are independent of the target smart
cards as they rely on the existence of standard GlobalPlatform functionality (while, for non-GlobalPlatform
cards, other scripts will need to be developed apart from the GlobalPlatform scripts). The instructions
contained within a script may include some cryptographic functionality such as generating personalization
session keys.

prohibited.
In the Application Profiles, the keys used by each of the scripts are defined. In turn, the card customization
system will reference the appropriate Key Profiles identified by these keys in order to retrieve necessary
information and behavior characteristics of the key. Thus, the Key Profiles enable locating (and using) the
cryptographic keys: examples include a “master” DES key for deriving session keys or an application provider
MAC key for performing MAC operations on personalization APDU commands
The card issuer (or the application provider) provides the personalization (master) keys used by these
cryptographic instructions.
The card creation scripts utilize references to data elements as defined in the Application Profiles. These
references need to be interpreted by the card customization system in order to:
• Import the actual load files containing the different applications code;
• By means of the data elements defined in the Application Profile and implementation dependent data
mapping, import, export, and update where specified, the actual data values defined in:
√ An optional card issuer (or application provider) static data file containing the data values
common to a specific batch of cards: examples include an activation date or key version identifier
that contains the same value for each card in a batch. Such a file would be present when the
personalization data file does not contain all of the required application personalization data;
√ The card issuer (or application provider) personalization data file containing the data values
unique to each card and cardholder: examples include a cardholder name, expiration date, or PAN.
The data mapping is specific to each personalization data file format and each card customization system. The
data mapping of data elements outside of the personalization data file is the implementation dependent
component of smart card customization since there is no way to know from an application developer standpoint
the name of parameters, keys, and data used in actual implementations. However, the application developer
would create scripts that would process the personalization data file, which would have been created with a data
preparation script written by the same application developer. Thus, the application developer always knows
what format the personalization data file will take when writing the personalization script for it.

prohibited.
Application
Development
Either an issuer or
managed database.
If a new GP Card Profile

Application is created with another
Unique ID, then it's
Code
returned to the SCMS.
Database System
If the GP Card Profile
uses another on-card
data item to manage the
Card card, a message with
Personalization Personalization Personalized information about that
System card is returned. To be
Data File Smart Cards
defined in future
messaging work.
Data Mapping
Static Data Files
GP Script
Interpreter GP Card Profile
Personalization XML Parser
Specific Card
Keys
Update
GP Card
JS
Profile
Perso GP Application
Script Profile(s)
SCMS will have to manage each

Conflict Check specific smart card issued. How it
manages cards is implementation
Card dependent.
Configuration
SCMS
XML Parser
Interface
Figure 3-4 – Work Flow for Pre-Issuance Card Customization

prohibited.
3.3.4 Customization Validation (or Verification)

Scripts can also be used to construct test cases for use in both the development of the application, as well as the
testing of personalized cards in production situations. One aspect, in particular, is customization verification,
which is used specifically for this latter task. Figure 3-5 summarizes the flows involved in testing
customization results using scripts.
The customization validation system, if it exists as a separate system, will implement the following card
customization components:
• Interface to receive profiles.
• XML parser to interpret and parse the Card Profile, and the Application Profile to determine which Key
Profiles are required, data elements which need to be mapped to the test personalization data file and
supplied static data files for testing, and the customization validation script to execute.
scripting objects, including external data and keys, data mapping to supplied test personalization data
file and static data files for testing, and finally, to execute the customization validation script to
customize the application onto the smart card.
A testing application, when implementing support for scripting, can use validation scripts to test the
performance and functionality of applications already personalized onto a card.

prohibited.
Either an issuer or
managed database.
Personalized
Database System Card(s) to Test
Data requirements in
testing will depend on
the nature of the test
scripts being executed.
Validation/
Test Data File
Testing System
Static Data Files Data Mapping

for Testing
GP Script
Interpreter Test Results
XML Parser
Test Keys
GP
Card
Profile Validation/Testing
System specific test
JS results
Test GP Application
Script Profile(s) Request additional
information if Card
Profile isn't sufficient.
Conflict Check
Card
Configuration
SCMS
XML Parser
Interface
SCMS will have to manage each

specific smart card issued. How it
manages cards is implementation
dependent.
Figure 3-5 – Work Flow for Customization Validation (or Verification)

prohibited.
The inputs to the customization verification system are:

• The script used for customization verification (data verification script),
• Verification parameters, unique per batch, the personalized smart cards, and optionally, the application
master keys.
The customization verification system audits a batch of customized smart cards by executing the instructions of
a data verification script and verifying the individual card and cardholder data read from the smart card against
the batch verification parameters file. The card issuer (or application provider) provides verification parameters
file for a particular batch.
The Data Verification Script instructions are typically independent of the audited smart cards. These
instructions may include some cryptographic functionality such as checking cryptograms based on card unique
keys. The application (master) keys used by these cryptographic instructions are provided by the card issuer (or
application provider).
Data verification scripts utilizes generic references to data elements as defined in the Application Profile.
These references need to be interpreted by the Customization Verification System in order to:
• Locate (and use) the cryptographic keys: examples include a “master” DES key for verifying a card
unique cryptogram or an application provider RSA public key for verifying a certificate
• Access the actual data values defined in the Application Profile:
• A card issuer (or Application Provider) parameters file containing the data values common or generic to
a specific batch of cards; examples include a key version identifier (common data with the same value
for each card in a batch) or a card number (generic data of a batch, incremented for each card, but
independent of any specific cardholder).
• Optional Card Issuer (or application provider) public key certificates signed by the application provider
Certification Authority.
The actual reference interpretation is specific to each personalization parameters file and each Customization
Verification system. The data mapping of data elements outside of the personalization data file is the
implementation dependent component of smart card customization since there is no way to know from an
application developer standpoint the name of parameters, keys, and data used in actual implementations.
3.3.5 Post Issuance Customization

Once cards have been issued, scripts will need to be provided to facilitate post-issuance operations. The post-
issuance customization process is fundamentally similar to the pre-issuance customization process with the
exception that typically only one smart card is personalized, and because of this, a post-issuance server
communicating with a post-issuance device facilitates customization. The post-issuance server establishes an
interface with a SCMS to facilitate transfer of the required scripts and profiles. The workflow for post-issuance
customization is illustrated in Figure 3-6.

prohibited.
Application
Development
Either an issuer or
managed database.
Application Personalized
Data requirements in Database System Smart Card
post-issuance will Code
depend on the operation
being performed on the
smart card.
Personalization Post-Issuance Post-Issuance

Data File Server Device
Data Mapping
Static Data Files
GP Script
Interpreter GP Card Profile
Personalization XML Parser
Keys Specific Card
Update
If a new GP Card Profile

GP Card is created with another
JS
Profile Unique ID, then it's
Other returned to the SCMS.
GP Application
Scripts Profile(s) If the GP Card Profile
uses another on-card
data item to manage the
card, a message with
information about that
Conflict Check card is returned. To be
defined in future
Card messaging work.
Configuration
SCMS
XML Parser
Interface
Figure 3-6 – Work Flow for Post-Issuance Card Customization

prohibited.
3.4 Responsibilities
The responsibilities of the different roles involved in the smart card customization process are detailed in the
CAMS model defined in [GP SYS_SCMS_REQ] but are summarized below:
3.4.1 Application Developer Responsibilities

The application developer:
• Acts under the control of the application provider (or card issuer for its own applications);
• Provides application code according to the application specification;
• Provides Application Profile.
3.4.2 Application Provider Responsibilities

The application provider:
• Enters in a partnership agreement with the card issuer;
• Adheres to the card issuer policies regarding smart card configuration and customization;
• Provides personalization parameters, personalization cardholder data file, and (optional) static data file
for its own applications;
• When allowed by the card issuer:
√ Receives the updated Card Profile generated by the card issuer for its own applications;
√ Configures for its own applications smart card products, that were originally defined by the card
issuer;
√ Generates itself or via an agent (e.g. a Personalization Bureau) a new updated Card Profile and
personalization scripts for its own applications;
√ Provides up to date Card Profile documents with up-to-date specific cardholder information.
• Otherwise, transfers Application Profiles of its own applications to the card issuer for smart card
configuration;
• Acts under the control of the application provider (or card issuer for its own applications);
• Defines Data Preparation, pre-issuance customization, post issuance customization, or Customization
Verification System implementation
3.4.3 Card Issuer Responsibilities

The card issuer:
• Enters in a partnership agreement with one (or more) Application provider(s);
• Defines its policies regarding smart card configuration and customization;
• Operates a SCMS or delegates SCMS responsibility to a Personalization Bureau;
• Defines and configures smart card products;

prohibited.
• Provides personalization parameters, personalization cardholder data file, and (optional) static data file
for its own applications;
• When agreed with the application provider:
√ Generates itself or via an agent (e.g. a Service Bureau) Card Profile documents reflecting up-to-
date specific cardholder information and personalization scripts for its own applications only;
√ Provides Card Profile documents with up-to-date specific cardholder information to the
Application Provider;
• Otherwise, generates itself or via an agent (e.g. a Personalization Bureau) updated Card Profile and
personalization scripts for all applications.
3.4.4 Card Manufacturer Responsibilities

The card manufacturer:
• Provides cards under contract for the card issuer;
• Provides Card Profile with potentially some unique card specific information (i.e. before the
customization process begins) and all its contents;
• Provides smart cards ready for production, i.e. for GlobalPlatform products in the state “OP_READY”
(no application other than “masked” is assumed to be resident);
• May offer customization services as a Personalization Bureau.
3.4.5 Application Loader Responsibilities

The application loader:
• Performs part or all of the smart card customization process by executing one or more than one type of
Customization script. More than one Personalization Bureau may be involved in the multi-application
customization process.

prohibited.
4. Profiles and Card Customization Process

GlobalPlatform Systems Profiles Specification 1.0 [GP_SYS_PRF]defines the structure and content of profiles.
Extensible Markup Language (XML) is the language to which the profiles will be created in. Using this widely
recognized markup language, XML Document Type Definition or XML Schema files can be created to define
the structure in a well understood, albeit simple, format for the profiles. The nature of XML makes it easy for
future changes to the content and structure of profiles to be changed and understood by the recipient systems.
This work represents an important first step to clarifying the types of information that need to be exchanged for
cards and applications. In concert with the GlobalPlatform Systems Scripting Specification 1.0
[GP_SYS_SCR]and this GlobalPlatform Card Customization Guide [CP_SYS_CCG] 1.0 (see Figure 1-1), the
XML models defined in GlobalPlatform Systems Profiles Specification 1.0 [GP_SYS_PRF] provide the
starting point for guiding interoperable smart card implementations. In future specifications, such as the
GlobalPlatform Messaging Specification, which will define how GlobalPlatform profiles are requested and
supplied, the XML components will become important building blocks for the various messages that need to be
exchanged This will be reflected in the GlobalPlatform Messaging Specification v1.0 under Development
[GP_SYS_MSG]
Table 4-1Error! Reference source not found. provides a summary of the different profiles, which are defined
in GlobalPlatform Systems Profiles Specification 1.0 [GP_SYS_PRF]
Profile Name Description

Card Profile The Card Profile describes a smart card. This card
could be a singularly unique card or a card that
shares common characteristics, as defined in the
Card Profile, with other cards. Depending on how it
is used, it either acts as a base template for a smart
card or represents a single smart card by itself.
Application Profile The Application Profile describes a smart card

application, independent of any particular smart
card.
Load File Profile The Load File Profile describes the application code
file that could contain one or more applications or
describe for an application one of the load files that
may make up that application code.
Key Profile The Key Profile describes a cryptographic key,

independent of any particular instance of the key. It
acts as a template for creating the actual key.
Table 4-1 – Summary of Profiles

prohibited.
4.1 Application Profiles

Application Profiles contain the scripts necessary to customize the application, including the Data Preparation
and card creation scripts. The actors, which provide the Application Profiles to the SCMS, also provide the
scripts necessary to customize their application. The Application Profiles contain the scripts as well as the data
element references and key references required for script execution.
Application Profiles, like other profiles, are uniquely identified by an attribute which identifies the owner of the
Application Profile and uniquely distinguishes the profile amongst the owner’s other Application Profiles. This
attribute is a combination of the owner’s ISO supplied Object Identifier (OID) and a owner specified unique
value.
The Script Interpreter needs access to the data within the profiles in the object structure defined in the
GlobalPlatform Systems Scripting Language Specification 1.0 [GP_SYS_SCR]. This object structure basically
mirrors the tree structure of the source XML profiles. However, certain parts of the Application Profile will be
converted in a manner which makes it easier to reference data elements and keys when writing customization
scripts. Furthermore, certain profiles, such as the Key Profile, or parts of the Application Profile, such as the
Script Fragments, will not be converted at all within the Scripting Interpreter, as the script developer doesn't
require them.
4.2 Card Profiles

The Card Profile contains the card template or image that describes every smart card which will be or has been
customized. Card Profiles, like other profiles, are uniquely identified by an attribute which identifies the owner
of the Card Profile and uniquely distinguishes the profile amongst the owner’s other Card Profiles. This
value.
Figure 4-1 and Figure 4-2 summarize the two typical scenarios of how Card Profiles can be used to manage a
card issuer’s smart card population.
In the first scenario illustrated in Figure 4-1, each unique or set of unique smart cards will have its own Card
Profile, and can be identified as such on the card with the Card Profile Unique Identifier loaded into Tag EE.
For cards without Tag EE populated with the Unique Identifer information, Appendix B outlines a more
generic methodology for card identification.
Where implementation dependent on-card data is used to manage individual smart cards and the Card Profile is
thus shared amongst a population of heterogeneous smart cards, such as the case in Figure 4-2, Card Profiles
contains references to these parameters. In the GlobalPlatform Systems Profiles Specification 1.0
[GP_SYS_PRF], these parameters are termed SCMS Fields.

prohibited.
Card Profile
Smart Card
Referenced
Personalized GP Card
Tag EE 'A' Smart Card Profile 'A'
Personalized GP Card
Tag EE 'B' Smart Card Profile 'B'
Figure 4-1 – Relationship between Card Profile and Card without SCMS
Card Profile
Smart Card
Referenced
Tag EE 'A' Personalized GP Card

SCMS Field '1' Smart Cards Profile 'A'
Figure 4-2 – Relationship between Card Profile and Cards with SCMS

prohibited.
It is important to remember that only two such usages of the Card Profile are illustrated. GlobalPlatform
Systems Profiles Specification 1.0 [GP_SYS_PRF] provides a means for standardizing information about cards.
How the Card Profile is used is entirely dependent on an implementation and how that implementation decides
to manage individual smart cards.
In addition, depending on the message being used to transport the Card Profile, it can represent different things.
If the message is a request for a Card Profile, then the Card Profile should be returned unaltered. However, if
the message is a request for information regarding a specific card in a card issuer’s smart card population, then
it is conceivable for the message to return a message formatted using the Card Profile schema including the
smart card’s card and application management information. In this case, only the format of the Card Profile is
being used to transport information about a specific card. The destination system will need to be cognizant that
the message being received is not a Card Profile even though it looks like one. The destination system is
receiving, in this case, the standard Card Profile with additional card specific information added. The
GlobalPlatform Messaging Specification [GP_SYS_MSG]will address these issues explicitly. For the time
being, implementers need to be wary of how they are using the Card Profiles.
Figure 4-3 provides examples of how Card Profiles could be used to manage the card as the card progresses
from the Chip Manufacturer to various card issuers. In this diagram, card issuer ABC decides to use only Card
Profiles to manage its customer/card relationships whereas card issuer GHI relies on a combination of the
standard Card Profile and an implementation specific SCMS Field defined in the Card Profile.

prohibited.
Chip Manufacturer
The card mask

is manufactured White
or purchased. Plastic
Manufacturer
adds core
software to the Tag EE written
chip and writes Tag EE 'A' to card with
a Tag EE value value 'A'
to the card.
GP Card Profile 'A'
Produced
Manufacturer
sells variants of
the chip to sell Issuer ABC Issuer DEF Issuer GHI
to their
customers. Tag EE 'B' Tag EE 'C' Tag EE 'D'
GP Card Profile 'B' is GP Card Profile 'C' is GP Card Profile 'D' is
GP Card Profile 'A' + GP Card Profile 'A' + GP Card Profile 'A' +
APP1 APP2 APP1 and APP2
Issuer ABC Issuer DEF Issuer GHI

receives card with receives card with receives card with
application APP1 application APP2 applications APP1
added by added by and APP2 added
manufacturer. manufacturer. by manufacturer.
Issuers
personalize
Personalized
their cards with GP Card Profile
Smart Cards
additional
applications and Tag EE 'D1' Personalized
Tag EE 'B1' 'B1' Smart Card
issues the cards SCMS Field '1'
to their Tag EE 'B2' 'B2' Tag EE 'D1' Personalized
customers. SCMS Field '2' Smart Card
Tag EE 'B3' 'B3'
GP Card
Issuer ABC uses GP Card Profiles to manage Profile 'D1'
their customer/card relationships. As a result,
each unique card will have an unique card Issuer GHI adds data to the card
profile. in order to manage the card/
customer relationship in their
SCMS. This becomes the SCMS
Field in a newly created card
profile.
Figure 4-3 – Examples of Using Tag EE and SCMS Fields

prohibited.
4.3 Load File Profiles

Information about the Load Files, such as CAP files for JavaCard applications, is required in the card
customization process for the standard load and install scripts. These scripts are executed under the control of
the Security Domain specified and use parameters supplied in both the Load File Profile and the Application
Profile to effect the loading and installation of Load Files onto a smart card.
Load File Profiles, like other profiles, are uniquely identified by an attribute which identifies the owner of the
Load File Profile and uniquely distinguishes the profile amongst the owner’s other Load File Profiles. This
value.
4.4 Key Profiles

Key Profiles are referenced in the Key definitions in the Application Profiles. The Script Interpreter needs
access to Key Profiles before the key objects can be correctly created in the scripting environment.
Key Profiles, like other profiles, are uniquely identified by an attribute which identifies the owner of the Key
Profile and uniquely distinguishes the profile amongst the owner’s other Key Profiles. This attribute is a
combination of the owner’s ISO supplied Object Identifier (OID) and a owner specified unique value.
Key Profiles are either defined by the application developer for keys of interest to the application only or are
defined and provided by the owners of the Key Management System (KMS) for keys requiring greater
cryptographic control.
4.5 Smart Card Identification Using Card Profiles

The process that Card Profiles and implementation could use specific SCMS Fields to identify smart cards as
they are presented to a personalization device is illustrated in Figure 4-4.

prohibited.
Inside the SCMS Database
GP Card Profile 'D1'
SCMS data on the card with the

SCMS Field specified in Card
Profile containing value of '1'
SCMS
Step 2 Step 4
Personalized Step 3
Smart Card
Step 1
Device
Tag EE 'D1'
SCMS Field '1'
Step 1.
Chip is accessible by a reader, which reads Tag EE
Step 2.
SCMS looks up Card Profile using the Tag EE value as the identifier
Step 3.
If a SCMS field is defined in the Card Profile, the SCMS requests that that value is read
from the smart card.
Step 4.
The card accessible by the device is uniquely identified. From card and application
lifecycle management capabilities, the SCMS has a complete and accurate card image.
Figure 4-4 – Smart Card Identification Using Card Profile

prohibited.
4.6 Role of Conflict Determination

Under GlobalPlatform, the information needed to personalize a card in either a pre-issuance or post-issuance
scenario originates from several entities, such as card manufacturers, Device Manufacturers, and application
providers. In order to provide a flexible solution where different applications can potentially be personalized
with physically differentiated cards on a variety of proprietary card personalization devices, a GlobalPlatform
implementation must be able to determine, to some extent, the compatibility of these applications, cards, and
devices. This conflict determination process can occur within a SCMS between cards, applications, and
devices, and can also occur for cards and applications outside the SCMS where conflict determination needs to
be done. Profiles provide sufficient conflict assessment information to determine what combinations of card,
device, and applications, respectively, can coexist for successful smart card customization to occur in concert
with GlobalPlatform environments.
As part of the card production process, card customization efforts can engage conflict determination several
times. It is up to the business rules of individual actors and any negotiated agreements with other actors to
determine if conflict determination needs to occur again whenever an application portfolio or a card Profile is
provided.
There is no standardized responsibility for creating Conflict Rules, but the resultant rules used by a SCMS to
perform conflict checks will be an amalgamation of rules provided in the profiles and rules provided by the
card issuer in the SCMS. Logically, there are a minimum set of rules which handle memory requirements and
platform compatibility. Within the profiles, elements need to be provided for the card manufacturers,
application providers and application developers to define explicit Conflict Rules for their cards, applications,
and devices, respectively.
The minimum Conflict Rules, such as ensuring that the combined memory used by an application portfolio is
physically within the resources of the selected smart card product, should be part of the default set of rules used
by a SCMS. However, it is suggested that they be present in all Card Profiles in order to ensure that the rules
are always present to avoid possible exclusion of these minimum conflict rules.
4.7 Conflict Determination Rules and Profiles

Conflict Determination Rules in the GlobalPlatform Card and Application Profiles give the ability to:
• Perform general comparisons between the source Profile against all other profiles of a certain type (card,
application, device);
• Perform specific comparisons between the target Profile (card, application, device) and a provided
value.
General guidelines for processing rules are as follows:
1. For rules associated with Card Profiles,
a. All rules comparing attributes between a Card Profile and an Application Profile must be
compared within and against all Application Profiles
b. Rules comparing an attribute in another profile and a provided constant value.
2. For rules associated with Application Profiles,
a. All rules with a target type of ApplicationProfile must be compared against all Application
Profiles to ensure that no conflicts exist or that any required dependencies are present.
b. Rules comparing an attribute in another GP Profile and a provided constant value.
prohibited.
Table 4-2 provides some examples of common rules that may exist.
It is suggested that these minimum rules be included in every Card Profile since there is no guarantee that every
system will implement them. By including them in every card Profile, the rules are guaranteed to be considered
by the system.
1. Card Profile’s Profile Version is the same as Application Profiles’ Profile Version;
2. Card Profile’s Platform Type is the same as Application Profiles’ Platform Type;
3. Card Profile’s Platform Version is the same as Application Profiles’ Platform Version;
4. Card Profile’s OS Platform is the same as Application Profiles’ OS Platform;
5. Card Profile’s OS Version is the same as Application Profiles’ OS Version;
6. If any Application Profiles require a CryptoEngine, then the Card Profile must contain a CryptoEngine
attribute;
7. If any Application Profiles require a Contactless card, then the Card Profile must contain a Contactless
attribute;
8. Card Profile’s RAM remaining must be greater or equal than the Application Profiles’ RAM;
9. Card Profile’s EEPROM remaining must be greater or equal than the Application Profiles’ EEPROM;
10. Any AIDs on the Card (of either Load File, Load Module, or application) currently must not conflict
with any AIDs a new application (regardless of it being for a Load File or Load Module);
a. Card Profile’s Load File AIDs doesn’t conflict with Application Profiles’ AIDs
b. Card Profile’s Module AIDs doesn’t conflict with Application Profiles’ AIDs
c. Card Profile’s Instance AIDs doesn’t conflict with Application Profiles’ AIDs
Resources
Description of Types of Additional Conflict Determination Rules
Involved
Card may have specific business rules which prohibit it from using certain applications
Cards or application portfolios. There exists a minimum set of conflict rules that must exist
in all Card Profiles.
Applications must be compatible with all the selected applications. Applications,

Applications which will not work in the presence of other applications already on the card, must not
be personalized.
All applications, which have interdependencies on other applications, require the

Applications
presence of the interdependent applications.
Load Files may indicate some interdependencies on other load files, or applications
Load Files
or cards.
Table 4-2 – Additional Conflict Determination Rules

prohibited.
4.8 Using Card Profiles to Track Updates to Personalized Smart

Cards
After the card customization process has been successfully completed, the Card Profile needs to be updated for
the cardholder(s) affected to reflect any changes to the Card Profile. If there are changes, it is highly
recommended that a new unique identifier be assigned to the Card Profile in order to protect Card Profile
integrity.
If no changes are made to the Card Profile or if it is insufficient to adequately describe the new state of the
smart card, information about the specific smart card in terms of card and application management data must be
returned to the requestor of card customization services in the return message. The format of this message will
be explicitly specified in the GlobalPlatform Messaging Specification [GP_SYS_MSG]
Implementation wise, it is important to note that entire Card Profiles do not need to be managed by a SCMS. If
this were the case, then as individual cardholders use and perform other customizations on their initially mass
issued smart cards into fully personalized (through post issuance activities in particular) smart cards,
management of Card Profiles will become unwieldy and expensive from a data storage perspective. It is
important for SCMS to only specifically manage the application and card lifecycle states of its cardholder base;
the SCMS will contain information for each of its supported card products and needs to have the capability to
construct profiles as required.

prohibited.
5. Scripting and Card Customization Process
5.1 Scripts Associated with Profiles

A generalized SCMS architecture with GlobalPlatform Profile interfaces and messaging flows is provided in
section 0. The illustration in this section also demonstrates the intertwined relationship with the requirements
of the GP Scripting Language defined in [GP_SYS_SCR].
In Application Development, the actors, which provide the profiles to the SCMS, also are the originators of the
profiles used by the GlobalPlatform scripting processes since the Application Profiles contain the scripts and
the data element references required for script execution. With the exception of checking for Device Profile
conflicts with the supplied application portfolio and selected smart card product, the Conflict Determination
process is the same regardless of where Conflict Determination occurs.
This particular argument is principally valid when the card configuration process is in a system separate from
the SCMS. When the card configuration process is functionality integrated into a SCMS, then the Card and
Application Profiles, need to be, in turn, supplied by the appropriate parties to the SCMS. Nonetheless, the
SCMS Card and Application Profiles can be extracted from these profiles to supply to other SCMS wherever
necessary.
5.2 Types of Scripts Used in Customization

For each application, there will be a minimum set of scripts that are present. These are data preparation scripts
and pre-issuance card customization script. They can also be used for an application in post-issuance scenarios.
Supplementary scripts that can be supplied with the Application Profile are scripts to be used once a card has
been issued (post-issuance card customization scripts) and card verification scripts.

prohibited.
5.2.1 Minimum Scripts
Table 5-1 defines the minimum scripts for every Security Domain Application Profile
Name of Script (a) Description

LOAD Loading the application’s Load File onto the smart card.
INSTALL Install the application from the Load File onto the smart card.
Initialize the application that has been loaded onto the smart
INITIALIZE
card.
Initialize the security domain that has been loaded onto the
INITIALIZE_SD
smart card.
Prepare the data used for personalization of the application.

The PERSOPREP script is used to create whatever format of
PERSOPREP
data the application requires. This could be a proprietary format,
a standard format such as Common Personalization, or XML.
Personalize the application using the data file that has been
PERSONALIZE
created by the PERSOPREP script.
Table 5-1 – Minimum Scripts for every Security Domain Application Profile
(a)
ScriptFragment Name in Application Profile
Table 5-2 defines the minimum scripts for every Application Profile
Name of Scripta Description

Prepare the data used for personalization of the application.
The PERSOPREP script is used to create whatever format of
PERSOPREP data the application requires. This could be a proprietary format,
a standard format such as Common Personalization, or XML, for
example.
Personalize the application using the data file that has been
PERSONALIZE
created by the PERSOPREP script.
Table 5-2 – Minimum Scripts for Application Profile
(a)
ScriptFragment Name in Application Profile

prohibited.
5.2.2 Supplementary Scripts

In addition to any custom stages specified by an application developer, Table 5-3 defines the suggested names
for additional standardized scripts that can be created.
Name of Script Description

Standardized script to validate whether the application has been
PERSOVERIF
personalized correctly onto the smart card.
LOADSCMSFIELD Retrieves the SCMS Field for the application from the smart card.
BLOCK Block an application.
UNBLOCK Unblock an application.
DELETE Delete an application instance.
DELETELF Delete an application load file.
BLOCKCARD Block a card.
OTHER Other scripts.
Table 5-3 – Supplementary Scripts

prohibited.
5.3 Suggested Use of Load/Install Scripts

For GlobalPlatform applications, load and/or install scripts are the property of Security Domains only. The
Application Profile, for a Security Domain, contains the mandatory LOAD INSTALL and INITIALIZE script
fragments. For a load and/or install action to be performed in the script environment, the following must be in
place:
• Configuration instructions defining which Security Domain to use to install/load an application. This
can be provided via the Card Profile and any SCMS information for the target smart card;
• Any application install parameters as provided by a SCMS or similar system;
• The Security Domain should be present on the card. If not, the Security Domain must be loaded and
installed;
• The Application Profile for the Security Domain in which the Load/Install will be executed. It is a XML
document that contains a Script Fragment for the desired Load/Install operation;
• The Script Fragment for the desired Load/Install operation should use parameters supplied as data
elements for the Load File Name as well as any application install parameters. This will enable the
script to be independent of the application being loaded and/or installed;
• If the application is not yet loaded onto the card, then a Load File and a Load File Profile must be
present. This XML document contains the AID of the Load Module containing the application as well
as the name of the Load File;
• Data Elements defined in the Application Profile at a global level (ApplicationProfile.DataElement) for
all the Security Domain’s scripts, and at a local level (ApplicationProfile.ScriptFragment.Declaration)
for individual script fragments. There is an implicit assumption that the script interpreter environment
for Load/Install operations provides a data mapping facility to map between the script/profile name for
the data and the application or issuer specific data source;
• Keys defined in the Application Profile at a global level (ApplicationProfile.Key) for all the Security
Domain’s scripts, and at a local level (ApplicationProfile.ScriptFragment.Key) for individual Script
Fragments.
The complete GP Scripting Language must be implemented in a Script Interpreter executing a Load/Install
Script. Figure 5-1 summarizes all the GP Scripting Language objects, which a Load/Install Script Fragment
could possibly utilize.
Figure 5-2 illustrates the Profile and script components necessary to execute koad/install scripts in the script
interpreter environment. Note from this diagram that the GP Application Profile and GP Load File Profile for
the application are not required for script execution. They should be used by the SCMS or similar system to
extract necessary parameters required by the data preparation script as Data Elements. Currently, there is no
means in the GP Scripting Language to access GP Load File Profile information directly in a means similar to
how GP Application Profile and GP Card Profile information is accessed. Hence, the only means to supply this
information is as data elements.
The objects that should be created prior to executing a Load/Install script are summarized in Figure 5-6.
Note that no objects are created for the application, as knowledge of the GP Profile for the application (as
opposed to the Security Domain) is not required in the Script Interpreter environment for Load/Install
operations. In fact, for the Load/Install, all GP Scripting Language method invocations are performed through
the SecurityDomain object created for the Security Domain under which the Load/Install will take place.

prohibited.
Built-in GPError Crypto GPSystem

GlobalPlatform
Scripting Objects
Application GPApplication GPSecurity
Domain
Secure GPScp01 GPScp02

Channel
Card Key
Native Atr Bytebuffer Bytestring TLV TLVList

GlobalPlatform
Scripting Objects
Figure 5-1 – Suggested GP Scripting Objects Available for Use by Load/Install Scripts

The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information is governed by the GlobalPlatform
license agreement and any use inconsistent with that agreement is strictly prohibited.
GP Card
XML The GP Card Profile for the target smart card.
Profile
Load/Install GP Application The GP Application Profile for the Security Domain from which Load/Install will be performed. This
JS XML XML Document will also contain script fragments for general Load/Install operations.
Script Fragments Profile
GP Key
XML GP Key Profiles for all the Keys used for the Load/Install Script Fragment.
Profile(s)
Access to all the Data Elements used for the Load/Install Script Fragment. At a minimum, these are
the ones defined in the ApplicationProfile.ScriptFragment.Declaration branch of the
Data Element XML document. The Load/Install Script Fragment should access Load File Name and application
Mapping install parameters as Data Elements, which will be provided by a SCMS or similar system. The
SCMS can obtain these values from the GP Application Profile and GP Load File Profile as
suggested below.
The GP Application Profile for the application to Load/Install. The

GP Application should be used to point to the correct GP Load File
GP Application
XML Profile using the ModuleID reference in the
Profile
ApplicationProfile.ApplicationInfo.Codes.Code
branch of the XML document.
The GP Load File Profile for the load file as required for Load/
GP Load File Install operations. The Module AID and filename of the load file
XML can be extracted from this file by the SCMS and mapped to the
Profile
data element used by the script fragment.
GP Application
XML The GP Application Profile for the Card Manager (or Issuer Security Domain), if available.
Profile
Figure 5-2 – Minimum Profile and Script Components for Load/Install Script

The GPSecurityDomain object is

GP Application created from the GP
JS XML Profile ApplicationProfile XML.
GP Scripts
For the Security Domain application, one GPSecurityDomain
object is created from the GP Application Profile corresponding
to the Security Domain application. From the GPApplication
object, this object is accessed as this.securityDomain. For
scripts executed for the Security Domain application, this
object becomes this.
GPSecurity
Domain
Key objects are created for, at a minimum, the Key
XML elements defined for the ScriptFragment
GPSecurity
element for the script under execution. Additional Key Data Profile Card Crypto
Object1 Object2 Domain
Keys from the Key XML under the root
ApplicationProfile element can be created. Keys are
accessed as this.key.keyname or
this.key[keyname] where keyname is the name
of the Key.
The GPApplication Pointer to a
object contains the Crypto object Pointer to a
Objects (ByteString, Number, and Boolean) are XML elements and used by the GPSecurityDomain
created for, at a minimum, the Declaration XML attributes, application. object created from
elements defined for the ScriptFragment for the script excluding the Key, a GP Application
under execution. Additional DataElements from the DataElement and Pointer to a Profile for the
DataElement XML under the root ApplicationProfile Declaration XML, Card object Security Domain
element can be created. DataElements are accessed as native created from under which this
as this.data.dataname or ECMAScript the GP Card one was installed.
this.data[dataname] where dataname is the objects. Profile.
name of the DataElement. The type of object created
depends on the Type attribute of the DataElement.
Function methods in GPSecurityDomain object from the Function XML

Function
Class1 in the GP Application Profile. Invoked via this.functionname
where functionname is the name of the function.
Figure 5-3 – Minimum Object Creation for Load/Install Script

5.4 Suggested Use of Data Preparation Scripts

For GlobalPlatform applications, usually a Data Preparation stage is required, especially for initial
personalization of the application onto the card (i.e., prior to pre-issuance personalization of the application).
The output of this Data Preparation stage is used as an input into subsequent personalization scripts, and this
Data Preparation is usually performed at a separate Data Preparation system with interfaces to a cryptographic
device as well as to application and card issuer specific data fields.
The output of the Data Preparation stage, (personalization data file), can be managed via the data element
objects defined in the GP Scripting Language. In the former case where data elements are used to manage the
personalization data file, the data elements must be identified and transported to the personalization device
executing the personalization script Fragment. In the latter case, the Application Profile could contain
functions to assist in file creation in the ApplicationProfile.Function branch of the XML document.
For the transport of personalization data information between systems, the data elements will follow a
standardized format in the relevant Data Preparation or card customization messages so that they can be
identified and utilized by requesting systems. Likewise, a means in the Data Preparation or card customization
message will be available to identify files that were created from the data preparation script, if the data
preparation script opted not to use data elements to store personalization data.
The Data Preparation System does not require access to the smart card, and thus should return exceptions if any
methods that interface with the target smart card are executed. Figure 5-4 proposes a lightweight
implementation of the GP Scripting Language objects specifically for Data Preparation Systems.
The Data Preparation component of the card customization process is facilitated through:
all the application scripts, and at a local level (ApplicationProfile.ScriptFragment.Declaration) for
individual Script Fragments. There is an implicit assumption that the Data Preparation System provides
a data mapping facility to map between the Script/Profile name for the data and the application or issuer
specific data source;
• Keys defined in the Application Profile at a global level (ApplicationProfile.Key) for all the application
scripts, and at a local level (ApplicationProfile.ScriptFragment.Key) for individual Script Fragments.
• A uniquely named Script Fragment with a stage name of PERSOPREP is set as a minimum requirement.
This is the script used for Data Preparation for the initial personalization of the application on the smart
card. This Script Fragment should not perform any smart card operations.
• Additional data preparation scripts for any post issuance operations can be added as application specific
Script Fragments. These Script Fragments should not perform any smart card operations.
• One object in the scripting language (TLV) that helps facilitate the navigation and processing of TLV
encoded data.
Figure 5-5 illustrates the Profile and script components necessary to execute Data Preparation scripts in the
Script Interpreter environment. Note that only the Application Profile containing the data preparation script for
the desired application needs to be provided. Card Profile or Application Profile information for other
applications on the card (i.e., Security Domains or Card Manager) are not required as no smart card operations
should be performed at Data Preparation.
At the Data Preparation System, prior to executing the data preparation script, the necessary objects are created
from the Application Profile as described in the GlobalPlatform Systems Scripting Language Specification 1.0.

prohibited.
Note, however, that since there is not requirement to access the target smart card, no Card object is created or
GPSecurityDomain object is created. The objects that should be created are summarized in Figure 5-6.

prohibited.
[Application,
GPApplication and
GPSecurityDomain
Objects]
Built-in GPError Crypto GPSystem The APDU related
GlobalPlatform methods do not have to
be implemented in a
Scripting Objects Data Preparation
System as no smart
card operations should
Domain
be performed.

[Atr, SecureChannel, GPScp01,
Channel
GPScp02, and Card Objects]
For a Data Preparation System, these
objects do not have to be implemented
Card Key at all since they require access to the
smart card.
Native Atr Bytebuffer Bytestring TLV TLVList

GlobalPlatform
Scripting Objects
Figure 5-4 –Suggested GP Scripting Objects Available for Use by Data Preparation Scripts

The GP Application Profile for the application for which data preparation is to be performed. The GP
Data Preparation GP Application Application Profile should include Script Fragments for data preparation; either the mandatory
JS XML PERSOPREP stage for initial personalization or any application specific post-issuance data
Script Fragments Profile
preparation script fragments.
GP Key GP Key Profiles for all the Keys used for the Data Preparation Script Fragment. At a minimum,
XML these are the ones defined in the ApplicationProfile.ScriptFragment.Key branch of the XML
Profile(s)
document.
Data Element Access to all the Data Elements used for the Data Prepration Script Fragment. At a minimum, these
Mapping are the ones defined in the ApplicationProfile.ScriptFragment.Declaration branch of
the XML document.
Figure 5-5 – Minimum Profile and Script Components for Data Preparation Script

The GPApplication object is

GP Scripts
No objects need to be created
for Card, Security Domain, or One GPApplication object is
Card Manager as they are not created for the GP Application
required for Data Preparation. Profile. It is the object from which
These properties should be left the script is executed, and is
empty for the GPApplication accessed as this.
object.
GPApplication

XML elements defined for the ScriptFragment element
Key Data Profile Crypto
for the script under execution. Additional Keys from Object1 Object2
the Key XML under the root ApplicationProfile element
can be created. Keys are accessed as
this.key.keyname or this.key[keyname]
where keyname is the name of the Key.
Access to cryptographic functions

DataElement objects are created for, at a minimum, required for data preparation.
the Declaration XML elements defined for the
ScriptFragment for the script under execution.
Additional DataElements from the DataElement XML
under the root ApplicationProfile element can be The GPApplication object
created. DataElements are accessed as contains the XML elements and
this.data.dataname or this.data[dataname] attributes, excluding the Key,
where dataname is the name of the DataElement. DataElement and Declaration
XML, as Profile objects.
Function methods in GPApplication object from the Function XML

in the GP Application Profile. Invoked via this.functionname
Function
Class1 where functionname is the name of the function. These could
be additional functions to help facilitate the data preparation
process for the application.
Figure 5-6 – Minimum Object Creation for Data Preparation Script

5.5 Suggested Use of Personalization Scripts

Once the personalization data file is created, a personalization script may be executed. Note that for post-
issuance personalization operations, a personalization data file is not mandatory depending on the nature of the
post-issuance Script Fragment.
For pre-issuance personalization, a minimum stage of PERSONALIZE is set aside for the Script Fragment. This
Script Fragment will operate on a personalization data file supplied either as data elements or as a file. In the
latter case, the contents of the file are accessed using the GP Scripting Language’s data element linkages or any
file access functions provided with the Application Profile in the ApplicationProfile.Function branch
of the XML document.
For GlobalPlatform applications, personalization scripts will be the property of the application. The application,
in turn, could be a Security Domain as well as a general application. In order for a personalization script
Fragment to be executed in the script environment, the following must be in place:
• If the Load File containing the application is not yet loaded onto the card, then a Load File Profile must
be present and the necessary Load/Install operation must be performed under a Security Domain so that
the Start Lifecycle of the application instance corresponds to the Start Lifecycle for the personalization
script. This Load File Profile XML document will contain the AID of the LOAD Module containing the
application as well as the name of the Load File;
• Configuration instructions as to which Security Domain to use for an application, if specified. This can
be provided via the Card Profile and any SCMS information for the target smart card;
• Any application parameters as provided by a SCMS or similar system;
• All data;
• The Security Domain should be present on the card. If not, then the Security Domain must be loaded
and installed;
• Application Profile for the Security Domain specified. This XML document must contain a Script
Fragment for the desired Secure Channel operations, namely at least a script for OpenSecureChannel;
• The Script Fragment for the desired personalization script Fragment should use any parameters supplied
as data elements from the SCMS or similar system. This will enable a single script to be used for
multiple configurations of the application;
all the application scripts, and at a local level (ApplicationProfile.ScriptFragment.Declaration) for
individual Script Fragments. There is an implicit assumption that the personalization device’s Script
Interpreter environment provides a data mapping facility to map between the script/profile name for the
data and the application or issuer specific data source;
• Keys defined in the Application Profile at a global level (ApplicationProfile.Key) for all the application
scripts, and at a local level (ApplicationProfile.ScriptFragment.Key) for individual Script Fragments.
The complete GP Scripting Language must be implemented in a Script Interpreter executing a Load/Install script.
Figure 5-7 summarizes all the GP Scripting Language objects, which a personalization script Fragment could
possibly utilize.
Figure 5-8 illustrates the Profile and script components necessary to execute personalization scripts in the Script
Interpreter environment.
The objects that should be created prior to executing personalization script are summarized in Figure 5-9.
prohibited.
Note that this is exactly the same object creation for applications as is mandated in the GlobalPlatform Systems
Scripting Language Specification 1.0, demonstrating that for personalization processes, the entire GP Scripting
Language object library is necessary.

prohibited.
Built-in GPError Crypto GPSystem

GlobalPlatform
Scripting Objects
Domain

Channel
Card Key DataElement Profile
Native Atr Bytebuffer Bytestring TLV

GlobalPlatform
Scripting Objects
Figure 5-7 –Suggested GP Scripting Objects Available for Use by Personalization Scripts

GP Card
XML The GP Card Profile for the target smart card.
Profile
Personalization GP Application The GP Application Profile for the Application from which the personalization script operation will be
JS XML performed.
Script Fragment Profile
GP Key
XML GP Key Profiles for all the Keys used for the Personalization Script Fragment.
Profile(s)
Access to all the Data Elements used for the Personalization Script Fragment. At a minimum, these
Data Element are the ones defined in the ApplicationProfile.ScriptFragment.Declaration branch of
Mapping the XML document. The Personalization Script Fragment may required parameters supplied by the
SCMS or similar system as Data Elements. These are in addition to Data Elements which contain
the personalization data file.
The GP Application Profile for the Security Domain under which the application was installed. This
GP Application Profile can be identified based on SecurityDomainAID information from the GP
GP Application
XML Card Profile for the target smart card. Alternatively, this can be identified by information held in the
Profile
SCMS in cases where the GP Card Profile provides only a partial image of the card (i.e., where a
SCMSField is used).
GP Application The GP Application Profile for the Card Manager (or Issuer Security Domain), if available. This may
XML be the same as the Security Domain under which the application was installed.
Profile
Figure 5-8 – Minimum Profile and Script Components for Personalization Script

The GPSecurityDomain object is

GP Scripts
For the Security Domain application, one GPSecurityDomain
object is created from the GP Application Profile corresponding
to the Security Domain application. From the GPApplication
object, this object is accessed as this.securityDomain. For
scripts executed for the Security Domain application, this
object becomes this.
GPSecurity
Domain
XML elements defined for the ScriptFragment
GPSecurity
element for the script under execution. Additional Key Data Profile Card Crypto
Object1 Object2 Domain
Keys from the Key XML under the root
ApplicationProfile element can be created. Keys are
accessed as this.key.keyname or
this.key[keyname] where keyname is the name
of the Key.
The GPApplication Pointer to a
object contains the Crypto object Pointer to a
Objects (ByteString, Number, and Boolean) are XML elements and used by the GPSecurityDomain
created for, at a minimum, the Declaration XML attributes, application. object created from
elements defined for the ScriptFragment for the script excluding the Key, a GP Application
under execution. Additional DataElements from the DataElement and Pointer to a Profile for the
DataElement XML under the root ApplicationProfile Declaration XML, Card object Security Domain
element can be created. DataElements are accessed as native created from under which this
as this.data.dataname or ECMAScript the GP Card one was installed.
this.data[dataname] where dataname is the objects. Profile.
name of the DataElement. The type of object created
depends on the Type attribute of the DataElement.
Function methods in GPSecurityDomain object from the Function XML

Function
Class1 in the GP Application Profile. Invoked via this.functionname
where functionname is the name of the function.
Figure 5-9 – Minimum Object Creation for Personalization Script

A. Integrated Example of Profiles and Scripts

Utilization
The examples outlined in this section assume the simplified set of actors and systems illustrated in Figure A- 1.
This section explores some of the exchanges of GP Profile information as well as the execution of GP scripts by
several of the actors summarized in this diagram.
UniversalChip
Chip Manufacturer
OID: None
UniversalChip supplies the

microchip used in the
MegaCard 1.0.0. ACME is
Bleinheim provides the
made aware of the chip details
JavaCard software and OP Smart Cards purchased by Yellow
necessary to construct the
Card Manager and Security Industries from ACME Corporation
GP Card Profile.
Domain applications for use are supplied to Reliable Systems
on ACME's MegaCard 1.0.0
Bleinheim
ACME Corporation Reliable Systems
SoftwareWorks UK Card Manufacturer Application Loader
Application Developer Bleinheim develops GP The GP Card Profile
OID: EEEEEEEEEE Application Profiles and OID:
RID: FFFFFFFFFF for the MegaCard Personalization
potentially sends to 1.0.0 is sent to both
Card Manufacturer. Device Issuance
bureau and issuer.
However, ACME is at
least made aware of the
platform and application Yellow will send GP Scripts and GP Profiles.
details and Other personalization data will be encapsulated in
requirements needed GlobalPlatform standard outlined in SCMS to
for the GP Card Profile Personalizatoin Bureau Interface specification.
it will construct.
Reliable Systems will execute the Personalization
Script Fragment for the PERSONALIZE stage.
Yellow Industries Reliable Networks

Card Issuer GP Scripts and GP Application Loader
Profiles (both GP
Card and Application) Personalization
Central SCMS are used in post- Device Post Issuance
issuance process.
AMS Systems Yellow Industries will

execute the Data
Preparation Scripts for Reliable Networks will
OID: AAAA
the two applicatoins. execute any post-
issuance
personalizatoin scripts
for the two
applications.
JavaMan is the Application
Provider who provides the final OP
Application Profile outlined in these
examples to the Card Issuer.
Yellow Industries then forwards the
files to their personalization bureau.
Payment Systems JavaMan's Application Loyalty Applications

Corporation Hut Company
Application Developer Payment Systems Application Provider Loyalty Applications Application Developer
Corporation provides Company provides
OID: DDDDDDDDDD OID: BBBBBBBBBB OID: CCCCCCCCCC
load files and OP load files and OP
Application Profiles for Application Profiles for
EasyChipPay. With LoyaltyApp. With the
the profiles, OP profiles, OP Scripts
Scripts will be included will be included for all
for all personalization personalization related
related activities for activities for the
the application. application.
Figure A- 1 – Examples of Interactions Using Profiles

prohibited.
A.1 The Actors
A.1.1 Card Manufacturer

ACME Corporation is the card manufacturer in this example. It offers a set of standard card products such as
standard GlobalPlatform 2.0.1 cards with the core applications like Card Manager masked into memory. The
following subsections examine the different card products and Card Profiles ACME Corporation could
potentially supply to its customers.
ACME Corporation Supplies Card Product with Core Applications Masked
Consider the case where the card manufacturer ACME Corporation designs and produces a GlobalPlatform 2.0.1
compliant card, which they market as the ACME MegaCard1.0.0. The MegaCard1.0.0 card is a JavaCard, and is
supplied with several core applications masked into memory, including a Card Manager and a Security Domain.
The particular implementation of GlobalPlatform 2.0.1, which ACME CORPORATION has selected, is
developed by Bleinheim SoftwareWorks UK. Other salient features of the MegaCard1.0.0 include a chip with
64K of RAM, 32K of ROM, 32K of EEPROM, and a public key crypto engine capability. The chip is
manufactured by UniversalChip and is known as the Hyena1.10. ACME Corporation creates and supplies the GP
Card Profile to every customer who purchases the ACME MegaCard1.0.0.
Since the core applications are masked, there is no need to provide the Application Profiles for these applications,
as further general information about these applications is no longer required, except for Security Domains. The
Application Profiles for the Card Manager and other Security Domains, for example, need to be made available
to the customer as Load/Install script fragments contained within these profiles may be required.
ACME Corporation decides to place a value for Tag EE onto the card corresponding to this particular card
product. It constructs the UniqueID for the Card Profile that will be placed in Tag EE using its OID (Hex
FFFFFFFFFF) and a five-byte field that it sets as Hex 0000000001. Therefore, the UniqueID value for this card
Profile is Hex FFFFFFFFFF0000000001. On the smart card, this is stored in Tag 6, which is then placed in Tag
EE. This is illustrated in Figure A- 2.
The XML documents supplied by ACME Corporation for the ACME MegaCard1.0.0 include a Card Profile for
the ACME MegaCArd1.0.0 and an Application Profile for Security Domain or Card Manager. This latter Profile
is not necessarily created by ACME Corporation, but they are responsible for supplying it with their smart card
order, as it would be required in Load/Install operations.
ACME Corporation Manufactures ACME Corporation Provides the
the ACME MegaCard 1.0.0 GP Card Profile
GP Card
ACME MegaCard
Profile
1.0.0
'FFFFFFFFFF0000000001'
Tag EE
Tag 6 contains 'FFFFFFFFFF0000000001'
Figure A- 2 - Smart Cards and GP Card Profile for ACME MegaCard 1.0.0
ACME Corporation Supplies Card Product with Additional Applications Loaded

Consider the case where the card manufacturer ACME Corporation adds several applications to their ACME
MegaCard1.0.0 product in response to a customer order. Specifically, ACME Corporation has decided to load an
install the payment application EasyChipPay on each of these cards, as their customer has requested they do so.
This application is not masked but loaded into RAM. For the payment application EasyChipPay, an application
Profile needs to be available to the customer.

prohibited.
ACME Corporation decides to place a value for Tag EE onto the card corresponding to this particular card
product. It constructs the UniqueID for the Card Profile that will be placed in Tag EE using its OID (Hex
FFFFFFFFFF) and a five-byte field that it sets as Hex 0000000002. Therefore, the UniqueID value for this card
Profile is Hex FFFFFFFFFF0000000002. On the smart card, this is stored in Tag 6, which is then placed in Tag
EE. This is illustrated in Figure A- 2.
Note that this differentiates this specialized card product from ACME Corporation’s standard ACME
MegaCard1.0.0 product.
The XML documents supplied by ACME Corporation for the ACME MegaCard1.0.0 are comprised of a Card
Profile for the ACME MegaCArd1.0.0, an Application Profile for Security Domain or Card Manager, and an
Application Profile for the payment application EasyChipPay. These latter two profiles are not necessarily
created by ACME Corporation, but they must be made available to the end customer.
ACME Corporation Adds
ACME Corporation Provides the
EasyChipPay application to the
GP Card Profile
ACME MegaCard 1.0.0
GP Card
ACME MegaCard 1.0.0
Profile
with EasyChipPay added
Tag EE
Tag 6 contains 'FFFFFFFFFF0000000002'
Figure A- 3 –Card and Card Profile for ACME MegaCard 1.0.0 with EasyChipPay
A.1.2 Chip Manufacturer

UniversalChip is the manufacturer of the microchip used by ACME Corporation in its MegaCard1.0.0 product
and any derivative card products. UniversalChip needs to supply the information required by ACME
Corporation to construct the Card Profiles for its card products. This could be supplied using a partial Card
Profile XML Document containing the information known by UniversalChip.
UniversalChip Provides a Partial
GP Card Profile
GP Card Profile
(with info known by Chip
Manufacturer)
Figure A- 4 – UniversalChip Supply Chip Information using a Partial Card Profile
A.1.3 Application Developer 1

Bleinheim SoftwareWorks UK is responsible for developing the GlobalPlatform 2.0.1 implementation used on
ACME Corporation’s MegaCard1.0.0 card products. Included in this implementation are the Card Manager and
Security Domain, for which Bleinheim provides the Application Profiles. These Application Profiles will contain
general purpose load/install scripts in order to facilitate loading and/or install operations under the Security
Domain.
Figure A- 5 illustrates the Profile and script components that Bleinheim must define at a minimum for its Security
Domain. This Application Profile must be made available to the end customer, and especially to the system
which ultimately performs load and/or install operations. As specified in the diagram, Bleinheim uniquely
identifies their Application Profile as Hex EEEEEEEEEE0000112233.

prohibited.
Bleinheim Provides the GP Application Profies
for Security Domain Applications
Load/Install GP Application Profile

JS XML
Script Fragments 'EEEEEEEEEE0000112233'
Figure A- 5 – GP Application Profile for Bleinheim’s Security Domain Application
A.1.4 Personalization Bureau

Reliable Systems acts as the personalization bureau. It has access to a personalization device that provides a
Script Interpreter environment to support the execution of Script Fragments.
Reliable Systems would perform Load/Install and Personalization operations primarily for pre-issuance of
Yellow Industries’ smart card products. Yellow Industries Is the card issuer and application provider. As
Reliable Systems likely has other customers besides Yellow Industries, they will keep a database of profiles,
including Application, Card and Load File Profiles. As well, the personalization device will have access to
cryptographic and key management functionality, which has an inventory of Key Profiles. It is assumed that
Reliable Systems knows where to request profiles if it does not have what it requires for a requested task.
The requirements for Load/Install and Personalization are as described in 5.3 and 5.5. Figure A- 6 provides an
illustration of the Profile and script requirements for Load/Install at Reliable Systems of the LoyaltyApp onto the
ACME MegaCard1.0.0 with EasyChipPay preloaded.
GP Card Profile The GP Card Profile for the target ACME MegaCard1.0.0 with EasyChipPay preloaded from ACME
XML Corporation.
The GP Application Profile from Bleinheim SoftwareWorks UK for the Security Domain from which
Load/Install GP Application Profile Load/Install will be performed. This XML Document will also contain script fragments for general
JS XML Load/Install operations. This Security Domain happens to be the Issuer Security Domain (Card
Script Fragments 'EEEEEEEEEE0000112233'
Manager) for the ACME MegaCard1.0.0 as well.
GP Key GP Key Profiles for all the Keys used for the Load/Install Script Fragment as specified in the GP
XML
Profile(s) Application Profile provided by Bleinheim SoftwareWorks UK.
Access to all the Data Elements used for the Load/Install Script Fragment. The Load/Install Script
Data Element Fragment should access Load File Name and application install parameters as Data Elements,
Mapping which will be provided by Yellow Industries' SCMS. The SCMS can obtain these values from the GP
Application Profile and GP Load File Profile for LoyaltyApp as suggested below.
GP Application The GP Application Profile provided by Loyalty Applications Company for the
XML LoyaltyApp application to Load/Install. The GP Application should be used to
Profile
point to the correct GP Load File Profile.
The GP Load File Profile provided by JavaMan's Application Hut for the load file
GP Load File as required for Load/Install operations. The Module AID and filename of the load
XML
Profile file can be extracted from this file by Yellow Industries' SCMS and mapped to the
data element used by the script fragment.
Figure A- 6 – Profile and Script for Load/Install at the Personalization Bureau

prohibited.
A.1.5 Post Issuance Service Provider

Reliable Networks is a partner company of Reliable Systems, and is in the business of providing post-issuance
services through their network of smart card enabled kiosks and wireless infrastructure supporting post-issuance
downloads to GSM enabled handsets.
Reliable Networks would perform Load/Install and Personalization operations in a post-issuance context. The
Application Owner, Yellow Industries, would still satisfy any Data Preparation requirements. Therefore, the
post-issuance servers owned by Reliable Networks would have implementations of the Script Interpreter
environment in order to execute the necessary Script Fragments.
A.1.6 Card Issuer and Application Owner

Yellow Industries acts as both the card issuer and the Application Owner. The systems in its domain include the
SCMS, and Application Management Systems for the EasyChipPay and LoyaltyApp applications. As well,
Yellow Industries does its own Data Preparation for these two applications, and would have at its disposal a Data
Preparation system with interfaces to cryptographic and key management services as required.
Yellow Industries will have an inventory of all profiles required to perform conflict resolution at its SCMS in
order to help it ascertain, with the assistance of supplemental business rules, what smart card products can be
offered to its consumers. As well, Yellow Industries will use the profiles in the Data Preparation process for
EasyChipPay and LoyaltyApp. It is assumed that Yellow Industries will know from where to request profiles it
requires but does not yet have.
Yellow Industries Supplies Updated GP Card Profiles for Personalized Cards
Consider the case where the ACME MegaCard1.0.0 cards corresponding to the Card Profile with an unique id of
Hex FFFFFFFFFF0000000002 (the standard ACME MegaCard1.0.0 with EasyChipPay preloaded) are
personalized by the card issuer Yellow Industries with an additional application in ROM, LoyaltyApp, and the
existing payment application EasyChipPay (for one of the cards) is personalized for the cardholder assigned to
the particular smart card. In this case, after personalization, the SCMS will manage the specific card by updating
the Card Profile associated with the card.
Rather than use a unique Card Profile for each individual smart card, the card issuer decides to manage these
issued cards using an application specific piece of data on the card, identified by a SCMSField element in the
Card Profile. In the Application Profile for this application, a Script Fragment could be provided to enable the
retrieval of this data from the card. For example, suppose Yellow Industries chooses a two-byte piece of data
known as the ‘FUD’ (Fidicuary Universal Delimiter) put on the card for the EasyChipPay application.
Yellow Industries would modify the Card Profile supplied by ACME Corporation. This new Card Profile would
contain an UniqueID specific to Yellow Industries constructed of its OID (Hex AAAA) and a five-byte identifier
chosen by Yellow Industries (Hex 0000000002). As well, the Card Profile would contain information about the
personalized EasyChipPay (an ApplicationInstance element) and LoyaltyApp (a LoadFileInstance as well as an
ApplicationInstance element) since these are standard for the product being offered by Yellow Industries. The
smart cards will have their Tag EE value changed to reflect this new Card Profile association (Hex
AAAA0000000002).
In the future, the Card Profile (Hex AAAA0000000002) will not be modified as these particular smart cards are
used. Instead, the SCMS itself will keep track of card and application management. If, at any time in the future,
there is a requirement for acceptance of Yellow Industries issued smart cards to be used at other card issuer’s
devices, the other card issuer will read the Tag EE value to determine the Card Profile required to form an image
of the card. Once the other card issuer retrieves the Card Profile from Yellow Industries, all the information
necessary to construct an precise image of the card can be discovered (i.e., the Card Profile will advise that the
card is managed by Yellow Industries’ SCMS using the ‘FUD’ value of the EasyChipPay application).

prohibited.
The card issuer will also have the Application Profile for the LoyaltyApp on hand in addition to the Application
Profile for EasyChipPay. This will be necessary to personalize the application using the scripts supplied with the
Application Profile, and also to perform any post-issuance or re-issuance personalization necessary for smart
cards with the application loaded.
The XML documents supplied by Yellow Industries include a new P Card Profile for the ACME MegaCard1.0.0
containing the reference to the SCMS Field used to manage the card in Yellow Industries’ SCMS.
Figure A- 7 illustrates four different smart cards issued by Yellow Industries in this example. The diagram also
shows only one GP Card Profile that is associated with all four cards. In this GP Card Profile, their would be a
SCMSField element with the Name attribute set to ‘FUD’.
Yellow Industries Adds LoyaltyApp and
Personalizes Smart Cards for their Customers
Tag EE 'AAAA0000000002'
SCMS Field 'FUD' '0001'
Tag EE 'AAAA0000000002'
Tag EE 'AAAA0000000002'
Tag EE 'AAAA0000000002'
GP Card Profile
XML 'AAAA0000000002'
Figure A- 7 – Four Personalized Smart Cards with One GP Card Profile

Payment Systems Corporation is one of two application developers in this example. It is responsible for the
specification, development, and testing of the EasyChipPay product. It would create the Application Profile for
EasyChipPay and provide this to authorized actors requesting this information. Yellow Industries is an
authorized actor in this example.
Payment Systems Corporation Supplies Application Profile for a Standalone Application
EasyChipPay
When the application developer Payment Systems Corporation develops the JavaCard code for their
EasyChipPay v1.0.0 application, part of the development process entails the creation of the requisite profiles and
GP scripts required to facilitate card management and broad personalization activities for the card. In this regard,
Payment Systems Corporation will provide an Application Profile, containing Script Fragments for the minimum
operations required (data preparation script and personalization script), as illustrated in Figure A- 8.

prohibited.
The Application Provider, JavaMan's Application Hut, supplies the application's Load File and Load File Profile.
However the UniqueIDs of the Application Profile doesn’t change from what Payment Systems Corporation
specified since JavaMan will not have changed the application at all. In this scenario, however, there is
communication between JavaMan and Payment Systems Corporation in order to include the correct ModuleID
and Module AID in each of the Application and Load File Profiles.
Payment Systems Corporation Provides the GP
Application Profile for EasyChipPay Application
Data Preparation
GP Application Profile
and Personalization JS XML
'DDDDDDDDDD0000001010'
Script Fragments
Figure A- 8 –Application Profile Created for EasyChipPay
Payment Systems Corporation Supplies Application Profile for New Release of an Application
Suppose that Payment System Corporation releases a new version of their EasyChipPay application that
incorporates several new features into it. A new Application Profile with new UniqueID for the
ApplicationProfile component would be released. This could be a revision on the previous version of the
Application Profile for EasyChipPay. As well, JavaMan will need to construct a new Load File (since it would
have changed to include the new application functionality) and a new Load File Profile.

Loyalty Applications Company is the second application developer in this example. It is responsible for the
specification, development, and testing of the EasyChipPay product. It would create the Application Profile for
EasyChipPay and provide this to authorized actors requesting this information. Yellow Industries is an
authorized actor in this example.
As Payment Systems Corporation did for the EasyChipPay v1.0.0 application; Loyalty Application Corporation
will provide the Application Profile for their LoyaltyApp application. The Application Provider, JavaMan's
Application Hut, supplies the application. However the UniqueIDs of the Application Profile doesn’t change
from what Loyalty Applications Company specified since JavaMan will not have changed the application at all.
In this scenario, however, there is communication between JavaMan and Loyalty Application Corporation in
order to include the correct ModuleID and Module AID in each of the Application and Load File Profiles.
A.1.9 Application Provider

As an application provider, JavaMan’s Application Hut packages the applications provided by the two
application developers into load files. JavaMan is responsible for working with the application developers to
ensure that the Application Profiles and Load File Profiles, which JavaMan creates, are in sync. JavaMan would
supply the Load File Profile for EasyChipPay (see Figure A- 9) and/or LoyaltyApp to authorized actors upon
request. Yellow Industries is an authorized actor in this example.
JavaMan's Application Hut Supplies Load File
Profile for Load File Containing EasyChipPay
GP Load File Profile

XML
'BBBBBBBBBBFFFFF00001'
Figure A- 9 – GP Load File Profile Created for EasyChipPay Application

prohibited.
B. Card Recognition Mechanism
B.1. General Mechanism

GlobalPlatform, in conjunction with MAOSCO and the Java Card Forum, has devised a scheme that will allow
an off-card system to discover how to work with a smart card of unknown characteristics without having to resort
to trial and error (which can be slow and unreliable). The idea is that the card may divulge ‘Card Recognition
Data’ at any time, and through it an off-card system can learn how to work with the card.
There are two aspects to this:
• The first is that a SELECT FILE command with no command data will select the card management
function on the card, and where appropriate will return the identifier of the card management function
for subsequent use.
• The second is that when the card management function on the card is selected, a GET DATA command
can be issued that will provide details of the card and how to access it, primarily for card management
purposes.
Issuing the GET DATA command for tag ‘66’ provides “Card Data”, which is TLV (tag-length-value) encoded
as described in ISO/IEC standard 7816-6. This in turn contains a constructed data object, Card Recognition Data,
with tag ‘73’. Card Recognition Data is unambiguously identified because it contains an object identifier that
GlobalPlatform has assigned for this purpose.
The method for accessing Card Recognition Data is as follows:
1. Use the SELECT FILE command (select by DF name) with no command data and with the “first or only
occurrence” option set. This selects the card management function on the card. Ignore any response
status other than ‘61xx’ or ‘6Cxx’.
2. Issue a GET DATA command as defined in ISO/IEC standard 7816-4 for a data object with tag ‘66’
(“Card Data”), and within that access Card Recognition Data (tag ‘73’) which contains the various card
recognition data objects. (Note that this command only returns the value field of “Card Data”, not its tag
or length.)
3. Check that the Card Recognition Data data object contains the GlobalPlatform “Card Recognition Data”
object identifier.
4. If this fails, then trial-and-error is necessary, as the card does not support Card Recognition Data.
Note that there may in future be a further option following step 1, but this relies upon obtaining a ‘neutral’ AID
for this purpose. The option would be that if step 1 gave an error status other than ‘6Cxx’, the SELECT FILE
command should be issued with the “neutral” AID, and any status other than ‘61xx’ or ‘6Cxx’ should be
ignored.

prohibited.
B.2. Object Identifier for Card Recognition Data

GlobalPlatform has an Object Identifier (OID) of
globalPlatform OBJECT IDENTIFIER ::= {iso(1) member-body(2) USA(840)
Global-Platform (114283)}
Within that, GlobalPlatform has assigned an Object Identifier of {Global-Platform 1} (that is,
{1 2 840 114283 1}) to mean “Card Recognition Data”:
cardRecognitionData ::= {globalPlatform 1}
By putting this Object Identifier into the Card Recognition Data data object, off-card systems can identify the
Card Recognition Data unambiguously. The Object Identifier identifies GlobalPlatform as the tag allocation
authority for application tags within the Card Recognition Data data object.
B.3 Application Tags

Within Card Recognition Data, GlobalPlatform will then assign application tags for the data objects required. The
scheme is what ISO/IEC standard 7816-6 refers to as a "compatible tag allocation scheme".
GlobalPlatform has already assigned some application tags, as follows:
(a) Tag APPLICATION 0 is used to identify the general class of card management function provided by the
card. The value field of this data object is an Object Identifier (OID) which would typically be based on
the OID of the organisation which operates the card management scheme. It might, for example, indicate
“John Doe's Proprietary Card Management Scheme Version 13”, or “MULTOS version 4”, or “OP
version 2.2”.
This data object is mandatory if Card Recognition Data is present. Tags 4 and 5 may or may not be
mandatory, depending on the rules of the operator of the card management scheme.
(b) Tag APPLICATION 3 identifies the scheme for card identifiers that is used for the card. The value field
of this data object is an Object Identifier (OID) which would typically be based on the OID of the
organisation which operates the card identification scheme. This, with its tag ‘06’ and length, when
added as a prefix to the “local” card identifier, forms a globally unique card identifier.
For example, the value field for a data object with this tag might contain an Object Identifier (OID)
indicating “John Doe's Patented Card Numbering Scheme”. If the card uses a field or data object “Card
Number” which is unique with John Doe cards, then a string
<‘06’ OIDLength OID cardNumber>
or
<‘06’ OIDLength OID anyTag cardNumberLength cardNumber>
can be used as a globally unique identifier for the card.
The APPLICATION 3 data object may or may not be mandatory, depending on the requirements of the
issuer and the operator of the card identification scheme.
(c) Tags APPLICATION 4 and 5 identify options within the card management scheme. Tag 4 may give
more detail of the primary secure protocol that the card supports for card management commands (if
appropriate) and tag 5 may give additional information on the card management system implementation
or card issuer options. The details and presence of these data objects and their contents will vary
according to the card management scheme as identified in the data object with tag APPLICATION 0.

prohibited.
(d) Tag APPLICATION 6 contains any proprietary identifiers. Implementers and issuers may put one or
more Object Identifiers in this data object to identify the exact implementation and/or behaviour of the
card platform, including any extensions or proprietary features. The presence of this data object depends
on the rules of the card issuer or card scheme.
GlobalPlatform may assign further application tags on request, for additional data that organisations may wish to
include. However, GlobalPlatform takes no responsibility for the information included, and does not guarantee its
interoperability. (Note that tags 1, 2 and 15 will not be assigned, as they are reserved by ISO.)
B.4 Contents of Data Objects

The meaning of the contents of the data objects needs to be made unambiguous. For example, card management
functions need to be uniquely identifiable. Thus in the examples given above, the John Doe Organization would
need to publish its object identifiers for identifying its products, versions, and card numbering scheme.
For GlobalPlatform cards, GlobalPlatform offers an identification scheme that can be used: see the
GlobalPlatform Card Specification for details.
B.5 Object Identifier Encoding

These sections provide additional information in the form of examples, but readers are advised to check details
against the original specifications such as the appropriate ITU recommendations and ISO standards.
An Object Identifier is presented as a series of integers, {a b c d e f...}. It is encoded as follows:
• The first byte codes 40a+b
• Each subsequent integer is converted to binary, and coded in as few bytes as possible, with most-
significant bit first and only using the least significant 7 bits of each byte. The high order bit of each
byte is set to 1 for all except the last (least significant) byte, where it is set to zero.
• All the values are coded contiguously.
The following example encodes the Object Identifier for {GlobalPlatform 1}, which is { 1 2 840 114283 1 }.
This is made up as summarized in Table B-1:
Object identifier Meaning

{1} ISO
{12} ISO member body
{ 1 2 840 } USA (ANSI)
{ 1 2 840 114283 } GlobalPlatform
{ 1 2 840 114283 1 } GlobalPlatform, Tag Allocation Authority for Card Recognition Data
Table B-1 – Example Representation of OID Value
The first byte is coded as 40a+b = 40*1+2 = 42 = hexadecimal ‘2A’, the remaining bytes code the other values,
as summarized in Table B-2:

prohibited.
Original hexadecima binary binary, binary coding hexadecima

Value l equivalent value base 128 with high order l coding
(7 bits per bit set
byte)
1 2 2A
840 348 11 0000110 10000110
01001000 1001000 01001000 8648
114283 1BE6B 1 0000110 10000110
10111110 1111100 11111100
01101011 1101011 01101011 86FC6B
1 1 1 0000001 00000001 01
Table B-2 – Example Coding of OID Value
And so the binary coding of the object identifier {GlobalPlatform 1} or { 1 2 840 114283 1 } is
‘2A864886FC6B01’.
B.6 Example of the Coding of Card Data with Card Recognition Data
Taking an example of a Joe Doe card, the example assumes a simple case where Joe Doe’s Object Identifiers are
summarized in Table B-3:
Object identifier value Meaning

{1} ISO
{12} ISO member body
{ 1 2 031 } Azerbaijan
{ 1 2 031 21 } Joe Doe Inc
{ 1 2 031 21 1 } Joe Doe’s Card Management System
{ 1 2 031 21 1 2 } Joe Doe’s Card Management System Version 2
{ 1 2 031 21 2 } Joe Doe’s Card Numbering Scheme
Table B-3 – Joe Doe’s Example OID Values
Assuming that Joe Doe Inc does not mandate the use of any of the optional tags, Card Data might then be coded
on 30 bytes as summarized in Table B-4:

prohibited.
Coding (hexadecimal) Meaning

66 Tag for Card Data
1C Length of Card Data (28 bytes)
73 Tag for Card Recognition Data
1A Length of Card Recognition Data (26 bytes)
06 Tag for Object Identifier, identifying this as Card Recognition Data
and naming the Tag Allocation Authority
07 Length of Object Identifier
2A864886FC6B01 Object Identifier for {GlobalPlatform 1} or {1 2 840 114283 1}
60 Tag APPLICATION 0
07 Length of card management function identifier
06 Tag for Object Identifier
2A1F150102 Object Identifier for Joe Doe’s Card Management System Version
2, {Joe Doe Inc 1 2} or { 1 2 031 21 1 2}
63 Tag APPLICATION 3
06 Length of card identification scheme identifier
06 Tag for Object Identifier
2A1F1502 Object Identifier for Joe Doe’s Card Numbering Scheme,
{Joe Doe Inc 2} or { 1 2 031 21 2}
Table B-4 – Coding of Joe Doe’s Card Data

prohibited.

GP Card Customization Guide v1.0

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GP Card Customization Guide v1.0

Uploaded by

Copyright:

Available Formats

GlobalPlatform

Card Customization Guide

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

4.3 LOAD FILE PROFILES ..................................................................................................................................50

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

1.4 Normative References

1.4.1 List of References

[GP SYS_SCMS_IMP] Provides a broad overview of the

[GP_SYS_CCG] Describe the major customization

GlobalPlatform Card Specification 2.0.1’ [GP_CARD_CS] Defines the requirements for a

Table 1-1: GP Normative References

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

Standard / Specification Remarks

ECMAScript – 3rd Edition (ECMA 262

Extensible Markup Language (XML) 1.0, W3C

ISO/IEC 7811-6: Identification cards --

ISO/IEC 7816-3: Information Technology –

ISO/IEC 7816-4: Information Technology –

ISO/IEC 7816-5: Identification Cards –

ISO/IEC 7816-6: Identification Cards –

ISO 8825 - International Standard

ISO 9797 – International Standard

Go to the following web site for Multos™ documentation:

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

Standard / Specification Remarks

Table 1-2: non GP Normative References

1.4.2 GlobalPlatform Document Navigation

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

1.5 Terminology and Definitions

Actor Unique entity participating in an GlobalPlatform compliant smart card

Instance of an Executable Module after it has been installed and made

The Application Profile describes a smart card application, independent of

Entity that owns an application and is responsible for the application's

The current life cycle state of an application on a GlobalPlatform smart

A cryptographic technique that uses two related transformations, a public

Card Image Number (CIN) An identifier for a specific OP card

Cardholder The end user of a card

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

Card personalization is defined in this document as the process of

Products are provided by card manufacturers. A product is an

Information that tells an external system, in particular a Card and

A DES encryption method where the results of the encryption of previous

This has been replaced with the specification GlobalPlatform Systems

A corporation that manufactures processor chips used in Smart Cards and

Description of the rules of compatibility between both Card and Application

Cryptogram The result of a cryptographic operation.

Copyright  2002 GlobalPlatform Inc. All Rights Reserved.

A Security Domain with a DAP Verification Privilege will perform the

Data Encryption Standard

The reversal of the corresponding encryption, reversible transformation of a

Delegated Management allows an Application Provider to load and install

Physical piece of hardware used in card Card Personalization, both pre-

Device Manufacturer A corporation which manufacturers devices

Used to contain minimum device related content in order for a SCMS to

An asymmetric cryptographic transformation of data that allows the recipient

A DES encryption method where one block of plaintext always encrypts to

The reversible transformation of data by cryptographic algorithm to produce

Actual on-card container of one or more application’s executable code