gp card customization guide v1.0

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.

GlobalPlatform Card Customization Guide

Version 1.0 13 August 2002

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

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.7 Application Developer 2 ....................................................................................................................77 A.1.8 Application Developer 3 ....................................................................................................................78 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

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

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

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 under GlobalPlatform;

• To describe how GP profiles and the GP Scripting Language should be used for card customization under GlobalPlatform;

• 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].



• 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.



1.4 Normative References

1.4.1 List of References

Standard / Specification Description

Multi Application Smart Card Management Systems GlobalPlatform Functional Requirements v3.4 May 2001

[GP SYS_SCMS_REQ] describes the necessary components for effectively managing the life cycle of an Open Platform multi application smart card and its related applications. Available at http://www.globalplatform.org/

GlobalPlatform A Primer to the Implementation of Smart Card Management and Related Systems v1.0, August 2000

[GP SYS_SCMS_IMP] Provides a broad overview of the processes involved in launching a multi application program and describes some of the initial services that issuers, vendors or system integrators may choose to implement. Available at http://www.globalplatform.org/

GlobalPlatform Card Customization Guide v1.0

[GP_SYS_CCG] Describe the major customization components required to implement the card customization 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’ GlobalPlatform Card Specification 2.1

[GP_CARD_CS] Defines the requirements for a GlobalPlatform smart card.

GlobalPlatform Systems Scripting Language Specification v1.0

[GP_SYS_SCR] Defines the language to use to create code to customize multi-application smart cards.

GlobalPlatform Systems Profiles Specification v1.0

[GP_SYS_PRF] Basic XML data structures used to describe smart cards, applications, and related entities

Table 1-1: GP Normative References



Standard / Specification Remarks

Borenstein, N. and Freed, N., Internet Engineering Task Force RFC 1521 Multipurpose Internet Mail Extensions (MIME) part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, September 1993.

[IETF_RFC1521] Defines the BASE64 format.

ECMAScript – 3rd Edition (ECMA 262 Standard)

[ECMA 262]

Extensible Markup Language (XML) 1.0, W3C Recommendation 10-Feb-98, REC-xml-19980210

[W3C_XML]

ISO/IEC 7811-6: Identification cards -- Recording technique -- Part 6: Magnetic stripe -- High coercivity, 2001.

[IS7811-6] Compact Numeric format defined.

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

[IS7816-3]

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

[IS7816-4]

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

[IS7816-5]

ISO/IEC 7816-6: Identification Cards – Integrated Circuit(s) Cards with Contacts – Part 6: Interindustry Data Elements, 1996

[IS7816-6]

ISO 8825 - International Standard Organization - Information Technology - ASN.1 Encoding Rules – 1995

[IS8825]

ISO 9797 – International Standard Organization

[IS9797]

Multos card Go to the following web site for Multos™ documentation: http://www.multos.com/



Standard / Specification Remarks PKCS #1 - RSA Laboratories - RSA Encryption Standard - Version 1.5 - November 1993

[PKCS#1]

Rivest, R., Internet Engineering Task Force RFC 132 - The MD5 Message-Digest Algorithm, April 1992.

The UniCode Consortium, The Unicode Standard - Version 3.2, March 2002.

[UNICODE] Defines the UTF-8 format.

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;



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.

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

Application profile The Application Profile describes a smart card application, independent of any particular smart card. It acts as a template for creating the actual application.

Application Protocol Data Unit (APDU)

Standard communication messaging protocol between a card accepting device and a smart card

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

Application Session The link between the application and the external world during a Card Session starting with the Application selection and ending with Application de-selection or termination of the Card Session

Application State The current life cycle state of an application on a GlobalPlatform smart card.

Asymmetric Cryptography

A cryptographic technique that uses two related transformations, a public transformation (defined by the Public Key component) and a private 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

Card Content Code and Application information (but not Application data) contained in the 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

Card Issuer Entity that owns the card and is ultimately responsible for the behavior of the card

Card Manager Generic term for the 3 card management entities of an Open Platform card i.e. the Open Platform Environment, Issuer Security Domain and the Cardholder Verification Method Services provider



Term Definition

(Smart) Card Manufacturer

Role that is responsible for producing (smart) cards on behalf of a Card Issuer. What services are performed depend on its contractual relationship with the Card Issuer and may include part or all of the card production process.

Card Personalization

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 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

Card Product Products are provided by card manufacturers. A product is an implementation of an operating system on a chip; it is a card ‘model.’ Some application instances may exist on a product (pre-loaded applications).

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.

Card Recognition Data Information that tells an external system, in particular a Card and Application Management System (CAMS), how to work with the card (including indicating that this is an OP card)

Card Session The link between the card and the external world starting with the ATR and ending with a subsequent reset or a deactivation of the card

Card Unique Data Data that uniquely identifies a card being the concatenation of the Issuer Identification Number and Card Image Number

Cipher Block Chaining

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 text block is dependent not just on the plaintext block that generated it but on all the previous plaintext blocks.

CCSB This has been replaced with the specification GlobalPlatform Systems Scripting Language Specification 1.0 and GlobalPlatform Systems Profiles Specification 1.0.

Chip Manufacturer A corporation that manufactures processor chips used in Smart Cards and Smart Card related form factor

Command A message sent by the host to the smart card that initiates an action and solicits a response from the smart card.

Conflict Determination Table

Description of the rules of compatibility between both Card and Application Profiles as used by Card Configurator functionality, whether this functionality resides within a Smart Card Management System or is resident elsewhere

Cryptogram The result of a cryptographic operation.



Term Definition

DAP Block Part of the Load File used for ensuring Load File Data Block verification

Data Authentication Pattern (DAP)

Used to authenticate and/or verify the integrity of the data. This can be done using a DES key or Public key mechanism.

DAP Verification Privilege A Security Domain with a DAP Verification Privilege will perform the verification of the Load File Data Block DAP.

Data Encryption Standard (DES)

A symmetric cryptographic algorithm.

Data Preparation The process of gathering and preparing the necessary application data and keys for input into the personalization device. The process can be driven by the Data Preparation Scripts provided in the Application Profile.

Decryption The reversal of the corresponding encryption, reversible transformation of a cryptogram by cryptographic algorithm to retrieve the original plain text data.

Delegated Management Delegated Management allows an Application Provider to load and install an application on a card, with the Card Issuer still retaining control over the content of the card.

Device Physical piece of hardware used in card Card Personalization, both pre-issuance and post-issuance or card acceptance scenarios

Device Manufacturer A corporation which manufacturers devices

Device Profile Used to contain minimum device related content in order for a SCMS to perform conflict determination

Digital Signature

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 sender and the recipient of the data against forgery by third parties; it also protects the sender against forgery by the recipient

Electronic Code Book (ECB) A DES encryption method where one block of plaintext always encrypts to the same block of cipher text; therefore each plaintext block is encrypted independently (see also Cipher Block Chaining).

Encryption The reversible transformation of data by cryptographic algorithm to produce a cryptogram.

Executable Load File

Actual on-card container of one or more application’s executable code (Executable Modules). It may reside in immutable persistent memory or may be created in mutable persistent memory as the resulting image of a Load File Data Block

Executable Module Contains the on-card executable code of a single application present within an Executable Load File

Host

A logical term used to represent the back end systems that support the Open Platform system; hosts perform functions such as authorization and authentication, administration, post-issuance application code and data downloading, and transactional processing



Term Definition

Immutable Persistent Memory Memory that can only be read

Issuer Identification Number (IIN)

The Issuer unique Identifier as defined in ISO 7812.

Issuer Security Domain On-card entity providing support for the control, security, and communication requirements of the card issuer

Key

A sequence of bits that controls the operation of cryptographic transformation. Keys are used in symmetric algorithms (secret keys, e.g., DES) and asymmetric algorithms (public key and private key pair, e.g., RSA).

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.

Life Cycle The existence of Card Content on an Open Platform card and the various stages of this existence where applicable

Life Cycle State A specific state within the Life Cycle of the card or of Card Content

Load File A file transferred to an Open Platform card that contains a Load File Data Block and possibly one or more DAP Blocks

Load File Data Block Part of the Load File that contains one or more application(s) and libraries 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

Load File Data Block Signature A value encompassing the Load File Data Block Hash and providing both integrity and authenticity of the Load File Data Block

MD5 One-way hash method to generate a 16 byte digital signature which is, in all 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

OS Platform

A smart card operating system or run-time environment that provides a consistent and hardware neutral execution environment for applications, ensuring inter-operability and portability of applications across products compliant to the same platform specification, independently of the product supplier.

Personalization Bureau A corporation delegated by a card issuer the responsibility to manage and personalize smart cards for that card issuer



Term Definition

Personalization Script

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),

• 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

Product Profile

Combination of a set of applications selected by an card issuer with a selected smart card platform. The product Profile is represented by a 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

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 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

Public Key Certificate An asymmetric transformation of the public key by a certification authority 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.



Term Definition

Smart Card Management System (SCMS)

Functionality which may be resident in an singular application or incorporated into existing card management systems that provides facilities for supporting the administration, personalization, and issuance of smart cards

SCMS Interface Interfaces between a Smart Card Management System and systems/applications resident at the same actor or at different actors. The interfaces will be used to transport Profile dat

Secure Channel A communication mechanism between an off-card entity and a card that provides a level of assurance, to one or both entities

Secure Channel Session A session, during an application session, starting with the Secure Channel Initiation and ending with a Secure Channel Termination or termination of either the application session or card session

Security Domain On-card entity providing support for the control, security, and communication requirements of the application provider

Smart Card Management System (SCMS)

Functionality which may be resident in an singular application or incorporated into existing card management systems that provides facilities for supporting the administration, personalization, and issuance of smart cards.

Symmetric Cryptography A cryptographic technique that uses the same secret key for both the originator's and the recipient's transformation

Token A mechanism from which the Card Manager on a card can determine whether or not pre-approval / pre-authorization from the Card Issuer was given to perform a given function.

Updated Card Profile

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 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



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



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



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.



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.



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.



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.



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



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.



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;



• 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.



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.



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.



GP Application Profile + GP Load File Profile

GP Card Profile

Profiles

ApplicationDevelopment

Data Prep. Script

PersonalizationData

Preparation

Perso. Data File (i.e., P3 file)Perso. Data File (i.e., P3 file)

External Data

Card Creation Script

CardPersonalization

Personalized Smart Cards

Data Verification Script

PersonalizationValidation Personalized

Smart Cards

SCMS

CardManufacturer

DeviceManufacturer

GP Card Profile

GP Application Profile + GP Load File Profile

GP Device Profile (Future)

Updated GPCard Profile1

and/or Specific Card Information2

Updated GPCard Profile1

and/or Specific Card Information2

XML Parser

Interface

Card Configuration

GP Script Interpreter

Post IssuancePersonalization

Application Specific Scripts

Personalized Smart Cards

Card Customization Messaging3

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]



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



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.



ApplicationSpecification


ApplicationCode

ApplicationTest/Verification

Test SmartCard

Application ProviderSigning Keys

Signed ApplicationCode

GP ApplicationProfile

XML JS

GP Scripts

XML

GP Load File Profile

Figure 3-2 – Work Flow for Application Development



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.



CardholderData File

Application/IssuerCertificates

ApplicationProvider

CertificateAuthority

Database System

Either an issuer orapplication providermanaged database.

PersonalizationParameters File

ApplicationKeys

PersonalizationData Preparation

Data Mapping

GP ScriptInterpreter

SCMS

CardConfiguration

Conflict Check

PersonalizationData File

Data mapping will useXML data elementinformation in the profile tomap data into the finalpersonalization data file

Data PrepScript

JSGP ApplicationProfile(s)

XML Parser

Figure 3-3 – Work Flow for Personalization Data Preparation



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.



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.



• Script interpreter implementing GP Scripting Language support in order to prepare the necessary 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.



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.




ApplicationCode

Database System


Static Data Files

PersonalizationKeys

CardPersonalization

System

Data Mapping


GP ApplicationProfile(s)

SCMS

CardConfiguration

Conflict Check

GP CardProfile


PersonalizedSmart Cards

GP Card Profile

If a new GP Card Profileis created with anotherUnique ID, then it'sreturned to the SCMS.

If the GP Card Profileuses another on-carddata item to manage thecard, a message withinformation about thatcard is returned. To bedefined in futuremessaging work.

XML ParserInterface

SCMS will have to manage eachspecific smart card issued. How itmanages cards is implementationdependent.

PersoScript

JS

Specific CardUpdate

XML Parser

Figure 3-4 – Work Flow for Pre-Issuance Card Customization



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.



• Script interpreter implementing GP Scripting Language support in order to prepare the necessary 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.



Test Data File

Database System


Static Data Filesfor Testing

Test Keys

Validation/Testing System

Data Mapping



GPCardProfile

PersonalizedCard(s) to Test

Test Results

Validation/TestingSystem specific testresults

Data requirements intesting will depend onthe nature of the test

scripts being executed.

TestScript

JS

XML Parser

SCMS

CardConfiguration

Conflict Check

XML ParserInterface

SCMS will have to manage eachspecific smart card issued. How itmanages cards is implementationdependent.

Request additionalinformation if Card

Profile isn't sufficient.

Figure 3-5 – Work Flow for Customization Validation (or Verification)



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.




ApplicationCodeDatabase System


Static Data Files

PersonalizationKeys

Post-IssuanceServer

Data Mapping



SCMS

CardConfiguration

Conflict Check

GP CardProfile


PersonalizedSmart Card

GP Card Profile

Post-IssuanceDevice

XML ParserInterface

Data requirements inpost-issuance will

depend on the operationbeing performed on the

smart card.

XML ParserSpecific CardUpdate

OtherScripts

JS

If a new GP Card Profileis created with anotherUnique ID, then it'sreturned to the SCMS.

If the GP Card Profileuses another on-carddata item to manage thecard, a message withinformation about thatcard is returned. To bedefined in futuremessaging work.

Figure 3-6 – Work Flow for Post-Issuance Card Customization



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;



• 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.



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



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 attribute is a combination of the owner’s ISO supplied Object Identifier (OID) and a owner specified unique 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.




GP CardProfile 'B'


GP CardProfile 'A''A'

'B'Tag EE

Tag EE

Card ProfileReferencedSmart Card

Figure 4-1 – Relationship between Card Profile and Card without SCMS


GP CardProfile 'A'

'A''1'

Tag EE

SCMS Field

Card ProfileReferencedSmart Card

Figure 4-2 – Relationship between Card Profile and Cards with SCMS



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.



WhitePlastic

Chip Manufacturer


GP CardProfile 'D1'

'D1''1'

Tag EE

SCMS Field

Tag EE writtento card withvalue 'A'

Tag EE 'A'

GP Card Profile 'A'Produced

Issuer ABCreceives card withapplication APP1added bymanufacturer.

Tag EE 'B'

Issuer DEFreceives card withapplication APP2added bymanufacturer.

Tag EE 'C'

Issuer GHIreceives card withapplications APP1and APP2 addedby manufacturer.

Tag EE 'D'

GP Card Profile 'B' isGP Card Profile 'A' +APP1

GP Card Profile 'C' isGP Card Profile 'A' +APP2

GP Card Profile 'D' isGP Card Profile 'A' +APP1 and APP2

Issuer ABC Issuer DEF Issuer GHI

Manufactureradds coresoftware to thechip and writesa Tag EE valueto the card.

Manufacturersells variants ofthe chip to sellto theircustomers.

Issuerspersonalizetheir cards withadditionalapplications andissues the cardsto theircustomers.

Issuer GHI adds data to the cardin order to manage the card/customer relationship in theirSCMS. This becomes the SCMSField in a newly created cardprofile.


'B1''B1'Tag EE

Issuer ABC uses GP Card Profiles to managetheir customer/card relationships. As a result,each unique card will have an unique cardprofile.

GP Card Profile

'B2'Tag EE

'B3'Tag EE

'B2'

'B3'

The card maskis manufacturedor purchased.


'D1''2'

Tag EE

SCMS Field

Figure 4-3 – Examples of Using Tag EE and SCMS Fields



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 attribute is a combination of the owner’s ISO supplied Object Identifier (OID) and a owner specified unique 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.



Step 1.Chip is accessible by a reader, which reads Tag EE

Device


'D1''1'

Tag EE

SCMS Field

SCMS

Step 1

Step 2

Step 3

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 readfrom the smart card.

Step 4

Step 4.The card accessible by the device is uniquely identified. From card and applicationlifecycle management capabilities, the SCMS has a complete and accurate card image.

GP Card Profile 'D1'

SCMS data on the card with theSCMS Field specified in CardProfile containing value of '1'

Inside the SCMS Database

Figure 4-4 – Smart Card Identification Using Card Profile



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.



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 Involved Description of Types of Additional Conflict Determination Rules

Cards Card may have specific business rules which prohibit it from using certain applications or application portfolios. There exists a minimum set of conflict rules that must exist in all Card Profiles.

Applications Applications must be compatible with all the selected applications. Applications, which will not work in the presence of other applications already on the card, must not be personalized.

Applications All applications, which have interdependencies on other applications, require the presence of the interdependent applications.

Load Files Load Files may indicate some interdependencies on other load files, or applications or cards.

Table 4-2 – Additional Conflict Determination Rules



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.



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.



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 Initialize the application that has been loaded onto the smart card.

INITIALIZE_SD Initialize the security domain that has been loaded onto the smart card.

PERSOPREP

Prepare the data used for personalization of the application. The PERSOPREP script is used to create whatever format of data the application requires. This could be a proprietary format, a standard format such as Common Personalization, or XML.

PERSONALIZE Personalize the application using the data file that has been 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

PERSOPREP

Prepare the data used for personalization of the application. The PERSOPREP script is used to create whatever format of data the application requires. This could be a proprietary format, a standard format such as Common Personalization, or XML, for example.

PERSONALIZE Personalize the application using the data file that has been created by the PERSOPREP script.

Table 5-2 – Minimum Scripts for Application Profile

(a) ScriptFragment Name in Application Profile



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

PERSOVERIF Standardized script to validate whether the application has been 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



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.



SecureChannel

Crypto GPSystem

Bytebuffer BytestringAtr TLV

GPScp01 GPScp02

Application GPApplication GPSecurityDomain

Card Key

Built-inGlobalPlatformScripting Objects

NativeGlobalPlatformScripting Objects

TLVList

GPError

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



GP CardProfileXML The GP Card Profile for the target smart card.

GP ApplicationProfileXML

The GP Application Profile for the Security Domain from which Load/Install will be performed. ThisXML Document will also contain script fragments for general Load/Install operations.

GP KeyProfile(s)XML GP Key Profiles for all the Keys used for the Load/Install Script Fragment.

Data ElementMapping

Access to all the Data Elements used for the Load/Install Script Fragment. At a minimum, these arethe ones defined in the ApplicationProfile.ScriptFragment.Declaration branch of theXML document. The Load/Install Script Fragment should access Load File Name and applicationinstall parameters as Data Elements, which will be provided by a SCMS or similar system. TheSCMS can obtain these values from the GP Application Profile and GP Load File Profile assuggested below.

GP Load FileProfileXML

The GP Load File Profile for the load file as required for Load/Install operations. The Module AID and filename of the load filecan be extracted from this file by the SCMS and mapped to thedata element used by the script fragment.

JSLoad/Install

Script Fragments

GP ApplicationProfileXML The GP Application Profile for the Card Manager (or Issuer Security Domain), if available.


The GP Application Profile for the application to Load/Install. TheGP Application should be used to point to the correct GP Load FileProfile using the ModuleID reference in theApplicationProfile.ApplicationInfo.Codes.Codebranch of the XML document.

Figure 5-2 – Minimum Profile and Script Components for Load/Install Script



GPSecurityDomain

CardObject1Key Object2Data Profile

JS

GP Scripts

XMLGP ApplicationProfile

For the Security Domain application, one GPSecurityDomainobject is created from the GP Application Profile correspondingto the Security Domain application. From the GPApplicationobject, this object is accessed as this.securityDomain. Forscripts executed for the Security Domain application, thisobject becomes this.

Key objects are created for, at a minimum, the KeyXML elements defined for the ScriptFragment

element for the script under execution. AdditionalKeys from the Key XML under the root

ApplicationProfile element can be created. Keys areaccessed as this.key.keyname or

this.key[keyname] where keyname is the nameof the Key.

Objects (ByteString, Number, and Boolean) arecreated for, at a minimum, the Declaration XML

elements defined for the ScriptFragment for the scriptunder execution. Additional DataElements from theDataElement XML under the root ApplicationProfile

element can be created. DataElements are accessedas this.data.dataname or

this.data[dataname] where dataname is thename of the DataElement. The type of object created

depends on the Type attribute of the DataElement.

Function methods in GPSecurityDomain object from the Function XMLin the GP Application Profile. Invoked via this.functionnamewhere functionname is the name of the function.

Class1Function

The GPSecurityDomain object iscreated from the GPApplicationProfile XML.

Crypto GPSecurityDomain

Pointer to aCard objectcreated fromthe GP CardProfile.

Pointer to aGPSecurityDomainobject created froma GP ApplicationProfile for theSecurity Domainunder which thisone was installed.

Pointer to aCrypto object

used by theapplication.

The GPApplicationobject contains theXML elements and

attributes,excluding the Key,DataElement andDeclaration XML,

as nativeECMAScript

objects.

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:

• Data Elements defined in the Application Profile at a global level (ApplicationProfile.DataElement) for 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.



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.



[Application,GPApplication andGPSecurityDomainObjects]The APDU relatedmethods do not have tobe implemented in aData PreparationSystem as no smartcard operations shouldbe performed.

[Atr, SecureChannel, GPScp01,GPScp02, and Card Objects]For a Data Preparation System, theseobjects do not have to be implementedat all since they require access to thesmart card.

SecureChannel

Crypto GPSystem


GPScp01


Key



GPScp02

Card

TLVList

GPError

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 GPApplication Profile should include Script Fragments for data preparation; either the mandatoryPERSOPREP stage for initial personalization or any application specific post-issuance datapreparation script fragments.

GP KeyProfile(s)XML

GP Key Profiles for all the Keys used for the Data Preparation Script Fragment. At a minimum,these are the ones defined in the ApplicationProfile.ScriptFragment.Key branch of the XMLdocument.

Data ElementMapping

Access to all the Data Elements used for the Data Prepration Script Fragment. At a minimum, theseare the ones defined in the ApplicationProfile.ScriptFragment.Declaration branch ofthe XML document.

JSData PreparationScript Fragments

Figure 5-5 – Minimum Profile and Script Components for Data Preparation Script



GPApplication

Object1Key Object2Data Profile

JS

GP Scripts


One GPApplication object iscreated for the GP ApplicationProfile. It is the object from whichthe script is executed, and isaccessed as this.

Key objects are created for, at a minimum, the KeyXML elements defined for the ScriptFragment element

for the script under execution. Additional Keys fromthe Key XML under the root ApplicationProfile element

can be created. Keys are accessed asthis.key.keyname or this.key[keyname]

where keyname is the name of the Key.

DataElement objects are created for, at a minimum,the Declaration XML elements defined for theScriptFragment for the script under execution.

Additional DataElements from the DataElement XMLunder the root ApplicationProfile element can be

created. DataElements are accessed asthis.data.dataname or this.data[dataname]

where dataname is the name of the DataElement.

The GPApplication objectcontains the XML elements andattributes, excluding the Key,DataElement and DeclarationXML, as Profile objects.

No objects need to be createdfor Card, Security Domain, orCard Manager as they are notrequired for Data Preparation.

These properties should be leftempty for the GPApplication

object.

Function methods in GPApplication object from the Function XMLin the GP Application Profile. Invoked via this.functionnamewhere functionname is the name of the function. These couldbe additional functions to help facilitate the data preparationprocess for the application.

Class1Function

The GPApplication object iscreated from the GPApplicationProfile XML.

Crypto

Access to cryptographic functionsrequired for data preparation.

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;

• Data Elements defined in the Application Profile at a global level (ApplicationProfile.DataElement) for 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.



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.



SecureChannel

Crypto GPSystem


GPScp01 GPScp02


Card Key DataElement Profile



GPError

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



GP CardProfileXML The GP Card Profile for the target smart card.


The GP Application Profile for the Application from which the personalization script operation will beperformed.

GP KeyProfile(s)XML GP Key Profiles for all the Keys used for the Personalization Script Fragment.

Data ElementMapping

Access to all the Data Elements used for the Personalization Script Fragment. At a minimum, theseare the ones defined in the ApplicationProfile.ScriptFragment.Declaration branch ofthe XML document. The Personalization Script Fragment may required parameters supplied by theSCMS or similar system as Data Elements. These are in addition to Data Elements which containthe personalization data file.

JSPersonalization

Script Fragment


The GP Application Profile for the Card Manager (or Issuer Security Domain), if available. This maybe the same as the Security Domain under which the application was installed.


The GP Application Profile for the Security Domain under which the application was installed. ThisGP Application Profile can be identified based on SecurityDomainAID information from the GPCard Profile for the target smart card. Alternatively, this can be identified by information held in theSCMS in cases where the GP Card Profile provides only a partial image of the card (i.e., where aSCMSField is used).

Figure 5-8 – Minimum Profile and Script Components for Personalization Script



GPSecurityDomain

CardObject1Key Object2Data Profile

JS

GP Scripts


For the Security Domain application, one GPSecurityDomainobject is created from the GP Application Profile correspondingto the Security Domain application. From the GPApplicationobject, this object is accessed as this.securityDomain. Forscripts executed for the Security Domain application, thisobject becomes this.

Key objects are created for, at a minimum, the KeyXML elements defined for the ScriptFragment

element for the script under execution. AdditionalKeys from the Key XML under the root

ApplicationProfile element can be created. Keys areaccessed as this.key.keyname or

this.key[keyname] where keyname is the nameof the Key.

Objects (ByteString, Number, and Boolean) arecreated for, at a minimum, the Declaration XML

elements defined for the ScriptFragment for the scriptunder execution. Additional DataElements from theDataElement XML under the root ApplicationProfile

element can be created. DataElements are accessedas this.data.dataname or

this.data[dataname] where dataname is thename of the DataElement. The type of object created

depends on the Type attribute of the DataElement.

Function methods in GPSecurityDomain object from the Function XMLin the GP Application Profile. Invoked via this.functionnamewhere functionname is the name of the function.

Class1Function

The GPSecurityDomain object iscreated from the GPApplicationProfile XML.

Crypto GPSecurityDomain

Pointer to aCard objectcreated fromthe GP CardProfile.

Pointer to aGPSecurityDomainobject created froma GP ApplicationProfile for theSecurity Domainunder which thisone was installed.

Pointer to aCrypto object

used by theapplication.

The GPApplicationobject contains theXML elements and

attributes,excluding the Key,DataElement andDeclaration XML,

as nativeECMAScript

objects.

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.

ACME CorporationCard Manufacturer

RID: FFFFFFFFFFOID: FFFFFFFFFF

BleinheimSoftwareWorks UK

Application Developer

OID: EEEEEEEEEE

UniversalChipChip Manufacturer

OID: None

Payment SystemsCorporation


OID: DDDDDDDDDD

Loyalty ApplicationsCompany


OID: CCCCCCCCCC

JavaMan's ApplicationHut

Application Provider

OID: BBBBBBBBBB

Yellow IndustriesCard Issuer

Central SCMS

Reliable SystemsApplication Loader

PersonalizationDevice Issuance

Reliable NetworksApplication Loader

PersonalizationDevice Post Issuance

Smart Cards purchased by YellowIndustries from ACME Corporationare supplied to Reliable Systems

The GP Card Profilefor the MegaCard1.0.0 is sent to bothbureau and issuer.

Bleinheim provides theJavaCard software and OPCard Manager and SecurityDomain applications for useon ACME's MegaCard 1.0.0

Bleinheim develops GPApplication Profiles andpotentially sends toCard Manufacturer.However, ACME is atleast made aware of theplatform and applicationdetails andrequirements neededfor the GP Card Profileit will construct.

GP Scripts and GPProfiles (both GPCard and Application)are used in post-issuance process.

Yellow Industries willexecute the DataPreparation Scripts forthe two applicatoins.

Loyalty ApplicationsCompany providesload files and OPApplication Profiles forLoyaltyApp. With theprofiles, OP Scriptswill be included for allpersonalization relatedactivities for theapplication.

Payment SystemsCorporation providesload files and OPApplication Profiles forEasyChipPay. Withthe profiles, OPScripts will be includedfor all personalizationrelated activities forthe application.

Yellow will send GP Scripts and GP Profiles.Other personalization data will be encapsulated inGlobalPlatform standard outlined in SCMS toPersonalizatoin Bureau Interface specification.

Reliable Systems will execute the PersonalizationScript Fragment for the PERSONALIZE stage.

JavaMan is the ApplicationProvider who provides the final OPApplication Profile outlined in these

examples to the Card Issuer.Yellow Industries then forwards thefiles to their personalization bureau.

UniversalChip supplies themicrochip used in the

MegaCard 1.0.0. ACME ismade aware of the chip details

necessary to construct theGP Card Profile.

AMS Systems

Reliable Networks willexecute any post-issuancepersonalizatoin scriptsfor the twoapplications.

OID: AAAA

Figure A- 1 – Examples of Interactions Using Profiles



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 MegaCard1.0.0

GP CardProfile'FFFFFFFFFF0000000001'

Tag 6 contains 'FFFFFFFFFF0000000001'Tag EE

ACME Corporation Provides theGP Card Profile

ACME Corporation Manufacturesthe ACME MegaCard 1.0.0

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.



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 MegaCard 1.0.0with EasyChipPay added

GP CardProfile'FFFFFFFFFF0000000002'

Tag 6 contains 'FFFFFFFFFF0000000002'Tag EE

ACME Corporation Provides theGP Card Profile

ACME Corporation AddsEasyChipPay application to theACME MegaCard 1.0.0

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.

GP Card Profile(with info known by ChipManufacturer)

UniversalChip Provides a PartialGP Card Profile

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.



Bleinheim Provides the GP Application Profiesfor Security Domain Applications

GP Application Profile'EEEEEEEEEE0000112233'XMLJS

Load/InstallScript Fragments

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'FFFFFFFFFF0000000002'XML

GP Application Profile'EEEEEEEEEE0000112233'XML

GP KeyProfile(s)XML

Data ElementMapping

GP Load FileProfileXML

JSLoad/Install

Script Fragments


The GP Card Profile for the target ACME MegaCard1.0.0 with EasyChipPay preloaded from ACMECorporation.

The GP Application Profile from Bleinheim SoftwareWorks UK for the Security Domain from whichLoad/Install will be performed. This XML Document will also contain script fragments for generalLoad/Install operations. This Security Domain happens to be the Issuer Security Domain (CardManager) for the ACME MegaCard1.0.0 as well.

GP Key Profiles for all the Keys used for the Load/Install Script Fragment as specified in the GPApplication Profile provided by Bleinheim SoftwareWorks UK.

Access to all the Data Elements used for the Load/Install Script Fragment. The Load/Install ScriptFragment should access Load File Name and application install parameters as Data Elements,which will be provided by Yellow Industries' SCMS. The SCMS can obtain these values from the GPApplication Profile and GP Load File Profile for LoyaltyApp as suggested below.

The GP Load File Profile provided by JavaMan's Application Hut for the load fileas required for Load/Install operations. The Module AID and filename of the loadfile can be extracted from this file by Yellow Industries' SCMS and mapped to thedata element used by the script fragment.

The GP Application Profile provided by Loyalty Applications Company for theLoyaltyApp application to Load/Install. The GP Application should be used topoint to the correct GP Load File Profile.

Figure A- 6 – Profile and Script for Load/Install at the Personalization Bureau



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).



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’.

'AAAA0000000002''0001'

Tag EE

SCMS Field 'FUD'

Yellow Industries Adds LoyaltyApp andPersonalizes Smart Cards for their Customers

'AAAA0000000002''0002'

Tag EE

'AAAA0000000002''0003'

Tag EE

'AAAA0000000002''0004'

Tag EE

GP Card Profile'AAAA0000000002'XML

SCMS Field 'FUD'

SCMS Field 'FUD'

SCMS Field 'FUD'

Figure A- 7 – Four Personalized Smart Cards with One GP Card Profile

A.1.7 Application Developer 2 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.



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 GPApplication Profile for EasyChipPay Application

GP Application Profile'DDDDDDDDDD0000001010'XMLJS

Data Preparationand Personalization

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.

A.1.8 Application Developer 3 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 FileProfile for Load File Containing EasyChipPay

GP Load File Profile'BBBBBBBBBBFFFFF00001'XML

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



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.



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.



(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

{ 1 2 } 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:



Original Value

hexadecimal equivalent

binary value

binary, base 128 (7 bits per

byte)

binary coding with high order

bit set

hexadecimal coding

1 2 2A840 348 11

0100100000001101001000

10000110 01001000 8648

114283 1BE6B 11011111001101011

000011011111001101011

10000110 11111100 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

{ 1 2 } 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:



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

gp card customization guide v1.0

Documents