0% found this document useful (0 votes)

296 views113 pages

GP Messaging Specification v1.0 (031014)

Uploaded by

Alfi Alireza

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

296 views113 pages

GP Messaging Specification v1.0 (031014)

Uploaded by

Alfi Alireza

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

GlobalPlatform Messaging

Specification
Version 1.0

October 2003

Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page i

Table of Contents

1. INTRODUCTION.............................................................................................................................. 1
1.1 INTENDED AUDIENCE ....................................................................................................................... 2
1.2 SCOPE ........................................................................................................................................... 2
1.3 NORMATIVE REFERENCES ............................................................................................................... 2
1.4 ABBREVIATIONS AND NOTATIONS ..................................................................................................... 4
1.5 CONVENTIONS ................................................................................................................................ 5
1.6 OBJECTIVES ................................................................................................................................... 5
2. ACTORS ROLES AND RESPONSIBILITIES ................................................................................. 7
2.1 PLATFORM SPECIFICATION OWNER .................................................................................................. 9
2.1.1 Platform Specification Owner’s Processing Flow.................................................................. 9
2.2 PLATFORM DEVELOPER ................................................................................................................... 9
2.2.1 Platform Developer’s Processing Flow ............................................................................... 10
2.3 IC MANUFACTURER ...................................................................................................................... 10
2.3.1 IC Manufacturer’s Processing Flow .................................................................................... 11
2.4 CARD MANUFACTURER.................................................................................................................. 11
2.4.1 Card Manufacturer’s Processing Flow ................................................................................ 12
2.5 CARD ENABLER ............................................................................................................................ 12
2.5.1 Card Enabler’s Processing Flow ......................................................................................... 14
2.6 APPLICATION OWNER .................................................................................................................... 14
2.6.1 Application Owner’s Processing Flow ................................................................................. 15
2.7 APPLICATION DEVELOPER ............................................................................................................. 15
2.7.1 Application Developer’s Processing Flow ........................................................................... 16
2.8 APPLICATION PROVIDER ................................................................................................................ 16
2.8.1 Application Provider’s Processing Flow .............................................................................. 17
2.9 CARD ISSUER ............................................................................................................................... 19
2.9.1 Card Issuer’s Processing Flow............................................................................................ 20
2.10 COLLATOR/DECOLLATOR ........................................................................................................... 22
2.10.1 Collator/Decollator’s Processing Flow................................................................................. 23
2.11 LOADER .................................................................................................................................... 24
2.11.1 Loader’s Processing Flow ................................................................................................... 25
2.12 CARDHOLDER............................................................................................................................ 26
3. DATA EXCHANGE MATRIX ......................................................................................................... 27
3.1 CARD ISSUER DATA EXCHANGE ..................................................................................................... 28
3.1.1 Card Issuer [CI] to Card Enabler [CE]................................................................................. 28
3.1.2 Card Issuer [CI] to Application Provider [AP] ...................................................................... 28
3.1.3 Card Issuer [CI] to Collator/Decollator [CD] ........................................................................ 28
3.2 CARD MANUFACTURER DATA EXCHANGE ....................................................................................... 29
3.2.1 Card Manufacturer [CM] to Card Issuer [CI] ....................................................................... 29
3.3 IC MANUFACTURER DATA EXCHANGE ............................................................................................ 29
3.3.1 IC Manufacturer [IM] to Card Manufacturer [CM]................................................................ 29
3.4 PLATFORM DEVELOPER DATA EXCHANGE ...................................................................................... 29
3.4.1 Platform Developer [PD] to IC Manufacturer [IM] ............................................................... 29
3.5 PLATFORM SPECIFICATION OWNER DATA EXCHANGE ..................................................................... 29
3.5.1 Platform Specification Owner [PS] to Platform Developer [PD] .......................................... 29
3.6 CARD ENABLER DATA EXCHANGE .................................................................................................. 30
3.6.1 Card Enabler [CE] to Card Issuer [CI]................................................................................. 30
3.7 APPLICATION DEVELOPER DATA EXCHANGE ................................................................................... 30
3.7.1 Application Developer [AD] to Application Owner [AO]....................................................... 30
3.8 APPLICATION OWNER DATA EXCHANGE ......................................................................................... 30
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page ii

3.8.1 Application Owner [AO] to Application Developer [AD]....................................................... 30

3.8.2 Application Owner [AO] to Application Provider [AP].......................................................... 31
3.9 APPLICATION PROVIDER DATA EXCHANGE ..................................................................................... 31
3.9.1 Application Provider [AP] to Card Issuer [CI] ...................................................................... 31
3.9.2 Application Provider [AP] to Card Enabler [CE] .................................................................. 31
3.9.3 Table Application Provider [AP] to Collator/Decollator [CD] ............................................... 31
3.10 COLLATOR/DECOLLATOR DATA EXCHANGE ................................................................................ 32
3.10.1 Collator/Decollator [CD] to Card Issuer [CI] ........................................................................ 32
3.10.2 Collator/Decollator [CD] to Application Provider [AP] ......................................................... 32
3.10.3 Collator/Decollator [CD] to Loader [LO] .............................................................................. 32
3.11 LOADER DATA EXCHANGE ......................................................................................................... 32
3.11.1 Loader [LO] to Collator/Decollator [CD] .............................................................................. 32
4. MESSAGE CATEGORIZATION.................................................................................................... 33

5. GLOBALPLATFORM MESSAGE STRUCTURE ......................................................................... 35

5.1 NAMESPACES ............................................................................................................................... 35
5.2 DATA TYPES AND STRING ENCODING ............................................................................................. 36
5.3 XML SCHEMA REFERENCES ......................................................................................................... 37
5.4 ENCRYPTION XML ........................................................................................................................ 37
6. MESSAGE HEADER ..................................................................................................................... 38
6.1 SIGNATURE XML ELEMENT ............................................................................................................ 40
7. MESSAGE BODY .......................................................................................................................... 41

8. APPLICATION PROFILE MESSAGE ........................................................................................... 44

8.1 APPLICATIONPROFILE ELEMENT ..................................................................................................... 44
8.2 PROFILEIDENTIFICATION ELEMENT ................................................................................................. 44
9. CARD PROFILE MESSAGE ......................................................................................................... 45
9.1 CARDPROFILE ELEMENT ................................................................................................................ 45
9.2 PROFILEIDENTIFICATION ELEMENT ................................................................................................. 46
10. CARD PROFILE CHANGES MESSAGE ...................................................................................... 47
10.1 APPLICATIONINSTANCES ELEMENT ............................................................................................. 48
10.2 LOADFILEINSTANCES ELEMENT .................................................................................................. 48
10.3 CARDINFO ELEMENT .................................................................................................................. 48
10.4 PROFILEIDENTIFICATION ELEMENT .............................................................................................. 48
11. KEY PROFILE MESSAGE ............................................................................................................ 49
11.1 KEYPROFILE ELEMENT ............................................................................................................... 49
11.2 PROFILEIDENTIFICTION ELEMENT ................................................................................................ 49
12. KEY EXCHANGE MESSAGE ....................................................................................................... 50

13. LOAD FILE PROFILE MESSAGE................................................................................................. 51

13.1 LOADFILEPROFILE ELEMENT ...................................................................................................... 51
13.2 PROFILEIDENTIFICATION ELEMENT .............................................................................................. 51
14. PROFILE REQUEST MESSAGE .................................................................................................. 52
14.1 PROFILEIDENTIFICATION ELEMENT .............................................................................................. 53
15. APPLICATION DATA NOTIFICATION MESSAGE...................................................................... 54

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

15.1 APPLICATIONCOMMONDATA ELEMENT ........................................................................................ 57

15.2 APPLICATIONDATAPERCRN ELEMENT ....................................................................................... 57
15.3 CRN ELEMENT .......................................................................................................................... 58
15.4 APPLICATIONDATA ELEMENT ...................................................................................................... 60
15.4.1 AID element......................................................................................................................... 60
15.4.2 ApplicationProfileUniqueID element.................................................................................... 61
15.4.3 Data element ....................................................................................................................... 61
15.4.4 DataSet element.................................................................................................................. 63
15.4.5 ICCData element................................................................................................................. 64
15.4.6 LogData element ................................................................................................................. 64
15.4.7 PersoDeviceIns element ..................................................................................................... 64
15.4.8 ProcessingStep element ..................................................................................................... 65
15.4.9 Script element...................................................................................................................... 66
15.4.10 Signature element............................................................................................................ 67
15.4.11 TransportKey element ..................................................................................................... 67
16. APPLICATION DATA REQUEST MESSAGE .............................................................................. 69
16.1.1 AID element......................................................................................................................... 69
16.1.2 CRN element ....................................................................................................................... 69
17. CARD CUSTOMIZATION MESSAGE........................................................................................... 70
17.1 MODULEIDENTIFIERCODE ELEMENT ............................................................................................ 72
17.1.1 CardConfiguration element ................................................................................................. 73
17.1.2 AID element......................................................................................................................... 73
17.1.3 CRN element ....................................................................................................................... 73
17.1.4 ValidCardProfileID element ................................................................................................. 74
17.1.5 ApplicationData element ..................................................................................................... 74
18. BATCH CARD CUSTOMIZATION MESSAGE ............................................................................. 75
18.1 ENVIRONMENTCONTAINER ELEMENT .......................................................................................... 78
18.2 JOBCONTAINER ......................................................................................................................... 79
18.3 DATACONTAINERHEADER .......................................................................................................... 79
18.4 COMMONDATACONTAINER ........................................................................................................ 80
18.5 COMMONMODULEIDENTIFIERCODE ............................................................................................ 81
18.6 CARDCOMMONCONFIGURATION ELEMENT .................................................................................. 81
18.6.1 AID element......................................................................................................................... 81
18.6.2 ValidCardProfileID element ................................................................................................. 82
18.7 APPLICATIONCOMMONDATA ELEMENT ........................................................................................ 82
18.7.1 ApplicationData element ..................................................................................................... 82
18.8 DATACONTAINER ...................................................................................................................... 82
18.8.1 ModuleIdentifierCode element ............................................................................................ 82
19. APPLICATION AUDIT TRAIL MESSAGE .................................................................................... 83
19.1 APPLICATIONCOMMONLOG ELEMENT .......................................................................................... 85
19.2 APPLICATIONLOG ELEMENT ........................................................................................................ 86
19.2.1 AID element......................................................................................................................... 86
19.2.2 ApplicationProfileUniqueID element.................................................................................... 86
19.2.3 ProcessingStepResult element ........................................................................................... 86
19.2.4 Data element ....................................................................................................................... 87
19.2.5 DataSet element.................................................................................................................. 87
19.2.6 Error element....................................................................................................................... 87
19.2.7 LogData element ................................................................................................................. 87
19.2.8 PersoDeviceIns element ..................................................................................................... 87
19.2.9 Script element...................................................................................................................... 87

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

19.2.10 Signature element............................................................................................................ 88

19.2.11 TransportKey element ..................................................................................................... 88
19.3 APPLICATIONLOGPERCRN ELEMENT ......................................................................................... 88
19.4 CRN ELEMENT .......................................................................................................................... 88
19.5 APPLICATIONLOG ELEMENT ........................................................................................................ 88
20. BATCH AUDIT TRAIL MESSAGE................................................................................................ 89
20.1 ENVIRONMENTCONTAINERLOG ELEMENT .................................................................................... 92
20.2 JOBCONTAINERLOG ELEMENT .................................................................................................... 92
20.3 LOGCONTAINERHEADER ELEMENT ............................................................................................. 93
20.4 COMMONLOGCONTAINER ELEMENT ............................................................................................ 94
20.5 LOGCONTAINER ELEMENT .......................................................................................................... 94
20.6 LOGIDENTIFIERCODE ELEMENT .................................................................................................. 94
20.6.1 AID element......................................................................................................................... 95
20.6.2 ApplicationLog element ....................................................................................................... 95
20.6.3 CardConfigurationLog element ........................................................................................... 95
20.6.4 CardLifeCycleState element ............................................................................................... 96
20.6.5 CollatorReturnCode element............................................................................................... 96
20.6.6 CRN element ....................................................................................................................... 96
20.6.7 Error element....................................................................................................................... 96
20.6.8 PhysicalCardIdentifier element ........................................................................................... 96
20.6.9 MuteCardsNumber element ................................................................................................ 97
20.6.10 ValidCardProfileID element ............................................................................................. 97
20.7 COMMONLOGIDENTIFIERCODE ELEMENT .................................................................................... 97
20.7.1 ApplicationCommonLog element ........................................................................................ 98
20.7.2 ApplicationLog element ....................................................................................................... 98
20.7.3 CardCommonConfigurationLog element............................................................................. 98
20.7.4 CollatorReturnCode element............................................................................................... 99
20.7.5 Error element....................................................................................................................... 99
20.7.6 ValidCardProfileID element ................................................................................................. 99
21. CARD AUDIT TRAIL MESSAGE ................................................................................................ 100
21.1 LOGIDENTIFIERCODE ELEMENT ................................................................................................ 102
22. ERROR ELEMENT ...................................................................................................................... 103

APPENDIX A: GPMESSAGES.1.0.0 XML SCHEMA FOR GLOBALPLATFORM MESSAGING ....... 104

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

List of Tables
Table 1-1 Normative References ................................................................................................................ 4
Table 1-2 Abbreviations and Notations....................................................................................................... 5
Table 3-1 Data Exchange Matrix .............................................................................................................. 27
Table 3-2 Card Issuer [CI] to Card Enabler [CE] ...................................................................................... 28
Table 3-3 Card Issuer [CI] to Application Provider [AP]............................................................................ 28
Table 3-4 Card Issuer [CI] to Collator/Decollator [CD] ............................................................................. 28
Table 3-5 Card Manufacturer [CM] to Card Issuer [CI]............................................................................. 29
Table 3-6 IC Manufacturer [IM] to Card Manufacturer [CM] ..................................................................... 29
Table 3-7 Platform Developer [PD] to IC Manufacturer [IM]..................................................................... 29
Table 3-8 Platform Specification Owner [PS] to Platform Developer [PD] ............................................... 29
Table 3-9 Card Enabler [CE] to Card Issuer [CI] ...................................................................................... 30
Table 3-10 Application Developer [AD] to Application Owner [AO] .......................................................... 30
Table 3-11 Application Owner [AO] to Application Developer [AD] .......................................................... 30
Table 3-12 Application Owner [8] to Application Provider [9] ................................................................... 31
Table 3-13 Application Provider [AP] to Card Issuer [CI] ......................................................................... 31
Table 3-14 Application Provider [AP] to Card Enabler [CE] ..................................................................... 31
Table 3-15 Application Provider [AP] to Collator/Decollator [CD]............................................................. 31
Table 3-16 Collator/Decollator [CD] to Card Issuer [CI] ........................................................................... 32
Table 3-17 Collator/Decollator [CD] to Application Provider [AP]............................................................. 32
Table 3-18 Collator/Decollator [CD] to Loader [LO].................................................................................. 32
Table 3-19 Loader [LO] to Collator/Decollator [CD].................................................................................. 32
Table 4-1 Message Categories................................................................................................................. 34
Table 5-1 GPMessage Attributes ............................................................................................................. 35
Table 5-2 Data Types................................................................................................................................ 36
Table 5-3 String Encodings for String Data Type ..................................................................................... 37
Table 6-1 GPHeader Attributes................................................................................................................ 40
Table 7-1 GPBody Attributes.................................................................................................................... 43
Table 8-1 AP Attributes ............................................................................................................................. 44
Table 9-1 CP Attributes ............................................................................................................................. 45
Table 9-2 ProfileIdentification Attributes............................................................................................... 46
Table 10-1 CPChanges Attributes ........................................................................................................... 47
Table 11-1 KP Attributes ........................................................................................................................... 49
Table 12-1 KeyExchange Attributes ....................................................................................................... 50
Table 13-1 LFP Attributes ......................................................................................................................... 51
Table 14-1 ProfileRequest Attributes...................................................................................................... 53
Table 15-1 ApplicationDataNotification Attributes............................................................................... 57
Table 15-2 ApplicationCommonData Attributes ................................................................................... 57
Table 15-3 ApplicationDataPerCRN Attributes...................................................................................... 58
Table 15-4 CRN Attributes ........................................................................................................................ 59
Table 15-5 ApplicationData Attributes ................................................................................................... 60
Table 15-6 CRN Attributes ........................................................................................................................ 61
Table 15-7 ApplicationProfileUniqueID Data Type .............................................................................. 61
Table 15-8 Data Attributes ....................................................................................................................... 63
Table 15-9 DataSet Attributes ................................................................................................................. 63
Table 15-10 ICCData Attributes............................................................................................................... 64
Table 15-11 LogData Attributes............................................................................................................... 64
Table 15-12 PersoDeviceIns Attributes .................................................................................................. 65
Table 15-13 ProcessingStep Attributes .................................................................................................. 66
Table 15-14 Script Data Type.................................................................................................................. 66
Table 15-15 TransportKey Attributes ..................................................................................................... 68
Table 16-1 ApplicationDataRequest Attributes .................................................................................... 69
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page vi

Table 17-1 CardConfiguration Attributes............................................................................................... 73

Table 17-2 ApplicationProfileUniqueID Data Type .............................................................................. 74
Table 18-1 BatchCardCustomization Attributes ................................................................................... 77
Table 18-2 EnvironmentContainer Attributes ....................................................................................... 78
Table 18-3 JobContainer Attributes ........................................................................................................ 79
Table 18-4 DataContainerHeader Attributes......................................................................................... 80
Table 18-5 CommonDataContainer Attributes ..................................................................................... 80
Table 18-6 CommonModuleIdentifierCode Attributes......................................................................... 81
Table 18-7 ApplicationCommonData Attributes ................................................................................... 82
Table 18-8 DataContainer Attributes...................................................................................................... 82
Table 19-1 ApplicationAuditTrail Attributes .......................................................................................... 85
Table 19-2 ApplicationCommonLog Attributes..................................................................................... 85
Table 19-3 ApplicationLog Attributes ..................................................................................................... 86
Table 19-4 ProcessingStepResult Attributes......................................................................................... 87
Table 19-5 ApplicationLogPerCRN Attributes........................................................................................ 88
Table 20-1 BatchAuditTrail Attributes.................................................................................................... 91
Table 20-2 EnvironmentContainerLog Attributes ................................................................................ 92
Table 20-3 JobContainerLog Attributes ................................................................................................. 93
Table 20-4 LogContainerHeader Attributes........................................................................................... 93
Table 20-5 CommonLogContainer Attributes ....................................................................................... 94
Table 20-6 LogContainer Attributes ....................................................................................................... 94
Table 20-7 LogIdentifierCod Attributes ................................................................................................. 95
Table 20-8 CardConfigutationLog Attributes ........................................................................................ 95
Table 20-9 CardLifeCycleState Attributes ............................................................................................. 96
Table 20-10 CollatorReturnCode Attributes .......................................................................................... 96
Table 20-11 PhysicalCardIdentifier Attributes ...................................................................................... 97
Table 20-12 MuteCardsNumber Attributes............................................................................................ 97
Table 20-13 CardCommonConfigurationLog Attributes ...................................................................... 98
Table 21-1 CardAuditTrail Attributes.................................................................................................... 102
Table 22-1 Error Attributes .................................................................................................................... 103

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

List of Figures
Figure 1-1 This Specification and Directly Related Documents ................................................................. 1
Figure 2-1 Actors and Interchanges ........................................................................................................... 8
Figure 2-2 Platform Developer’s Processing Flow ................................................................................... 10
Figure 2-3 IC Manufacturer’s Processing Flow......................................................................................... 11
Figure 2-4 Card Embedding Processing Flow .......................................................................................... 12
Figure 2-5 Card Enablement Processing Flow ......................................................................................... 14
Figure 2-6 Application development Subcontracting Processing Flow .................................................... 15
Figure 2-7 Application and Application Data Preparation Processing Flow ............................................. 18
Figure 2-8 Card Customization Processing Flow ..................................................................................... 21
Figure 2-9 Card Customizing Processing Flow ........................................................................................ 25
Figure 5-1 GPMessage XML Diagram ..................................................................................................... 35
Figure 6-1 GPHeader XML Diagram........................................................................................................ 38
Figure 7-1 GPBody XML Diagram............................................................................................................ 42
Figure 8-1 AP XML Diagram ..................................................................................................................... 44
Figure 9-1 CP XML Diagram ..................................................................................................................... 45
Figure 10-1 CPChanges XML Diagram ................................................................................................... 47
Figure 11-1 KP XML Diagram ................................................................................................................... 49
Figure 12-1 KeyExchange XML Diagram ............................................................................................... 50
Figure 13-1 LoadFileProfile XML Diagram ............................................................................................. 51
Figure 14-1 ProfileRequest XML Diagram.............................................................................................. 52
Figure 15-1 ApplicationDataNotification XML Diagram....................................................................... 56
Figure 16-1 ApplicationDataRequest XML Diagram ............................................................................ 69
Figure 17-1 CardCustomization XML Diagram ..................................................................................... 71
Figure 17-2 CardCustomization Attributes ............................................................................................ 72
Figure 17-3 ModuleIdentifierCode Attributes........................................................................................ 73
Figure 18-1 BatchCardCustomization XML Diagram ........................................................................... 76
Figure 18-2 CommonCardConfiguration Attributes ............................................................................. 81
Figure 19-1 ApplicationAuditTrail XML Diagram .................................................................................. 84
Figure 20-1 BatchAuditTrail XML Diagram ............................................................................................ 90
Figure 20-2 CommonLogIdentifierCode Attributes .............................................................................. 98
Figure 21-1 CardAuditTrail XML Diagram............................................................................................ 101
Figure 22-1 Error XML Diagram............................................................................................................. 103

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Revision History
Version Date Who Comments

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

1. Introduction
The GlobalPlatform systems infrastructure model is based on the concept of distinct infrastructural
components. This model was chosen for its simplicity, extensibility and for the fact that it allows
component developers to specialize in their areas of competence. However, in any particular
GlobalPlatform smart card infrastructure, systems from different vendors will be used. In line with
GlobalPlatform’s objective for open standards, this document addresses the standardization of
communication within the system infrastructure.

It is expected that this document be used in conjunction with other GlobalPlatform documentation.
The document map presented in Figure 1-1 illustrates this document as it relates to complementary
system documentation.

Device Card
Specification Specification

GP Application GP Key
SCMS SCMS
Developers Management
Minimum Functional
Guide System
Requirements Requirements
Requirements

GP Messaging GP Card
Specification Customization Guide

GP Load & Personalization GP Guide to GP Systems Profiles GP Systems

Interface Specification Common Personalization Specification Scripting Specification

Figure 1-1 This Specification and Directly Related Documents

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

1.1 Intended Audience

This document is targeted to Systems Developers and Systems Integrators participating in
GlobalPlatform smart card implementations. Such systems could include:
Data Preparation Systems
Personalization Systems
Application Management Systems
Smart Card Management Systems
Personalization Collators/Decollators

1.2 Scope
This document is limited to describing the format and data requirements when various components of
the systems infrastructure involved are required to communicate.

The following is in the scope of the document:

Card customization messages
Profile exchange messages
Post issuance messages
Error messages

The following is outside of the scope of the document:

Messaging protocol
System design
System and application specific features

1.3 Normative References

The documents specified in Table 1-1 are referenced in this specification

Standard / Specification Description

Defines the requirements for a GlobalPlatform smart card.
GlobalPlatform Card
Available at
Specification 2.1.1, 2003
http://www.globalplatform.org/
GlobalPlatform Systems Basic XML data structures used to describe smart cards,
Profiles Specification, 1.1, applications, and related entities. Available at
2003 http://www.globalplatform.org/
GlobalPlatform Systems Defines the language to use to create code to customize
Scripting Language multi-application smart cards. Available at
Specification, 1.1, 2003 http://www.globalplatform.org/

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Standard / Specification Description

Describes the major customization components required to
implement the card customization process, the
GlobalPlatform Systems
responsibilities for each of the major roles and how GP
Card Customization Guide,
profiles and the GP scripting language should be used for
1.0, 2002
card customization under GlobalPlatform. Available at
http://www.globalplatform.org/
GlobalPlatform Load and Describes a standard interface between a data preparation
Personalization Interface system and a personalization system. Available at
Specification, 1.0, 2003 http://www.globalplatform.org/
GlobalPlatform Guide to Provides detailed guidelines on how to implement the
Common Personalization, common personalization. Available at
1.0, 2003 http://www.globalplatform.org/
Provides detailed specification over the common
EMV Card Personalization
personalization approach adopted by EMV. Available at
Specification, 1.0, 2003
http://www.emvco.com/
Specifies XML digital signature processing rules and syntax.
W3C
XML Signatures provide Intergrity, message Authentication,
XML-Signature Syntax and
and/or signer authentication services for data of any type,
Processing,
whether located within the XML that includes the signature
W3C Recommendation 12
or elsewhere. Available at
February 2002
http://www.w3.org/

W3C specifies a process for encrypting data and representing the

XML-Encryption Syntax and result in XML. The data may be arbitrary data (including an
Processing, XML document), an XML element, or XML element content.
W3C Recommendation 10 Available at
December 2002 http://www.w3.org/

Extensible Markup
Language (XML) 1.0, W3C
[W3C_XML]
Recommendation 10-Feb-
98, REC-xml-19980210
ISO/IEC 7816-3:
Information Technology –
Identification Cards –
Integrated Circuit(s) Cards
[IS7816-3]
with Contacts – Part 3:
Electronic Signals and
Transmission Protocols, 2nd
Edition, 15 December 1997.
ISO/IEC 7816-4:
Information Technology –
Identification Cards –
Integrated Circuit(s) Cards
[IS7816-4]
with Contacts – Part 4:
Interindustry Commands for
Interchange, 1st Edition, 1
September 1995.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Standard / Specification Description

ISO/IEC 7816-5:
Identification Cards –
Integrated Circuit(s) Cards
with Contacts – Part 5:
[IS7816-5]
Numbering System and
Registration Procedure for
Application Identifier, 1st
Edition, 15 June 1994
ISO/IEC 8825 - International
Standard Organization -
Information Technology - [IS8825]
ASN.1 Encoding Rules –
1995
The UniCode Consortium,
The Unicode Standard - [UNICODE] Defines the UTF-8 format.
Version 3.2, March 2002.
“Namespaces in XML” [W3C NAMESPACES]
REC-xml-names-19990114 XML namespaces provide a simple method for qualifying
http://www.w3.org/TR/1999/REC- element and attribute names used in XML documents by
xml-names-19990114
associating them with namespaces identified by URI
references.
“XML Schema Part 1: [W3C SCHEMA1]
Structures” XML Schema: Structures specifies the XML Schema
http://www.w3.org/TR/2001/REC- definition language, which offers facilities for describing the
xmlschema-1-20010502/
structure and constraining the contents of XML 1.0
documents, including those which exploit the XML
Namespace facility.
“XML Schema Part 2: [W3C SCHEMA2]
Datatypes” XML Schema: Datatypes is part 2 of the specification of the
http://www.w3.org/TR/2001/REC- XML Schema language. It defines facilities for defining
xmlschema-2-20010502/
datatypes to be used in XML Schemas as well as other XML
specifications.
Table 1-1 Normative References

1.4 Abbreviations and Notations

Abbreviation Meaning
AID Application Identifier (see ISO/IEC 7816-5)
CIN Card Image Number / Card Identification Number
Logical Card Reference Number identifies a card with one or
CRN multiple application for identified cardholder. If the card is
replaced the CRN remains the same.
Europay, MasterCard, and Visa; used to refer to the ICC
EMV
Specifications for Payment Systems
IC Integrated Circuit
ICC Integrated Circuit Card
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 5/113

IPR Intellectual Property

ISK Initial Supplier Key
OID Object Identifier specified by ASN1.
OPEN GlobalPlatform Card Environment
PIN Personal Identification Number
RFU Reserved for Future Use
RID Registered Application Provider Identifier
ROM Read-only Memory
RSA Rivest / Shamir / Adleman asymmetric algorithm
SCMS Smart Card Management System
XML eXtensive Markup Language

Table 1-2 Abbreviations and Notations

1.5 Conventions
Text in Verdana Bold refers to elements and attributes from XML document type definition files,
XML schema files, XML documents, XML elements, and XML attributes.

1.6 Objectives
The objective of this document is to describe the standardized messages that need to be exchanged
between disparate systems in a GlobalPlatform smart card environment. Messages can be
exchanged between any number of parties, and in some cases the recipient may not necessarily be
the entity required to act on the message. However, it is the responsibility of the recipient system to
route the message on to the relevant party. The GlobalPlatform Messaging Specification's primary
objective is to standardize the most common messages that will be exchanged between disparate
systems from a range of suppliers. By creating standards for these fundamental messages, the
intention is to reduce systems integration impacts typically associated with constructing a systems
architecture from a variety of solution providers.

It is important to note that the objective of this specification is not to prescribe or specify messages
internal to a supplier of a system. Thus, where a supplier's product or product solution internalizes
the interchanges of two or more actors identified in this document, the implementation of these
particular interchanges is left to the design discretion of the supplier. In such instances, where the
product eventually needs to interface with other systems, the required messages for these interfaces
are defined in the GlobalPlatform Messaging Specification.

The messages described in the GlobalPlatform Messaging Specification all utilize a standard XML
message header. The purpose of a standardized header is to facilitate message identification by
systems utilizing this specification. This header will, at a minimum, describe:
Message Identifier
Message Type
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 6/113

Message Source
Message Recipient
Message Security

The messages described in this specification can be characterized into two different categories:
Messages for GlobalPlatform Profiles. These messages focus on card, application and key
management interchange.
Messages for GlobalPlatform Card Customization. These messages focus on
personalization data preparation and personalization enablement including post issuance
delete, load, install and personalization. This category includes audit trail messages.

Extensible Markup Language (XML) is the language of choice to structure messages. XML provides
the flexibility and standards based approach that messages require in order to be unambiguous,
support different versions of messages as they evolve, and be conducive to ease of information
parsing and maintenance. XML is easily adaptable by actors involved in the Card Personalization
process, and facilitates future changes in the content model as these changes need only be reflected
in the XML schemas used by message providers. As a result, XML as a choice to represent
messages is an open approach that should be tenable to everyone involved in smart card
implementations.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

2. Actors Roles and Responsibilities

There are various actors involved in the production, distribution and maintenance of a multi-
application smart card program. This section of the specification defines a simple model describing
the roles necessary in such programs. Figure 2-1 depicts this model and labels the interactions
between these roles. These labels will be useful when delving into message specifics elsewhere in
this specification.

Actors are the entities responsible for playing roles (i.e., taking actions). Roles are the functions to be
performed. Responsibilities describe more specifically the actions and the scope of actions that are
performed.

An actor may perform dual or even multiple roles. For example, a Card Issuer could conceivably also
be the Application Provider as well as the Loader. At a high level an actor can also perform roles that
appear similar or may be identical. At a lower level of detail, the specific responsibilities of actors
distinguish the roles they play.

In addition, several actors may combine responsibilities to accomplish a certain function. For
example, while there may be only one actor responsible for application loading, the Application
Provider or the Cardholders have responsibilities that result in the initiation of application loading. All
have some common set of responsibilities with respect to loading but each may deploy different
processes and instruments to acquire the application to be loaded.

Although this specification may be used to implement interfaces internal to a role, the GP Messaging
Specification does not dictate any interface or messaging exchanged internally to a role or even to an
actor performing multiple roles.

The following sections define the elements which need to be exchanged between the systems
supplied under the different roles. It is essential for an actor playing one or multiple roles to know
which data elements it is expected to send out and receive with respect to the messages exchanged.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Figure 2-1 Actors and Interchanges

Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 9/113

2.1 Platform Specification Owner

The Platform Specification Owner defines and maintains the card platform operating system
specifications. The GlobalPlatform consortium is the Platform Specification Owner for the
GlobalPlatform Specifications.

A platform is defined as the combination of:

the on-card functionality that is independent of applications and hardware,
the on-card administrative functions required to support applications,
and the off-card administrative functions required to facilitate the management of applications
to/from the card.

The Platform Specification Owner has the following responsibilities:

to develop and maintain the specification content and Type Approval requirements,
and to license the platform specifications to the Platform Developers, the Application
Developers and others as required.

To perform its responsibilities, the Platform Specification Owner should be able to:

1. Send to other actors:

a. Platform specification (to the Platform Developer [PD])

2.1.1 Platform Specification Owner’s Processing Flow

Figure 2-2 illustrates the Platform Specification Owner’s participation in the production lifecycle.

2.2 Platform Developer

The Platform Developer is responsible for the development of the GlobalPlatform cards according to
the Specifications provided by the GlobalPlatform consortium. The Actors playing this role will be
primarily those entities currently developing read-only memory (ROM) code for masking on Integrated
Circuits in the Smart Card industry, although other entities in different industry sectors may also
choose to do so.

The Platform Developer has the following responsibilities:

to select the appropriate target silicon on which the platform will reside,
to license the specifications from the Platform Specification Owner,
to design and produce code to satisfy the requirements of the specifications and the chip
device,
to securely deliver the code to and procure a mask from the IC Manufacturer,
to satisfy the Type Approval requirements specified by the Platform Specification Owner,
and to generate application profiles for the platform application components (i.e., card
manager and security domain applications).

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

To perform its responsibilities, the Platform Developer should be able to:

1. Receive from other actors:

a. Platform Specification (from the Platform Specification Owner [PS])

2. Send to other actors:

a. Binary Operating System (to the IC Manufacturer [IM])

2.2.1 Platform Developer’s Processing Flow

Figure 2-2 depicts the Platform Developer’s participation in the production lifecycle.

Platform Specification Owner Platform Developer IC Manufacturer

Sends Platform Receives Specification

Specification to the Platform
Developer

Develops the platform

Sends binary Operating Receives binary Operating

System to the IC System
Manufacturer

Figure 2-2 Platform Developer’s Processing Flow

2.3 IC Manufacturer
The entity that fabricates wafers containing chips with a specified ROM configuration. The Actors
playing this role will be primarily those entities currently manufacturing Integrated Circuits for the chip
card industry, although other entities in the silicon chip industry may also choose to do so.

The IC Manufacturer has the following responsibilities:

to accept ROM code from the Platform Developer,
to control the ROM masking process,
to securely receive the transport keys for a set of chips containing a particular platform from
the appropriate key management authority,
to securely load initial transport keys and/or certificates into the chip,
to operate under appropriate security and quality processes (e.g., accepted industry
practices, guidelines, standards, laws, regulations),
to securely deliver the chips to the Card Manufacturer,
and to generate the ISK along with a Key Profile.

To perform its responsibilities, the IC Manufacturer should be able to:

1. Receive from other actors:

a. Binary Operating System (from the Platform Developer [PD])
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 11/113

2. Send to other actors:

a. IC Information (to the Card Manufacturer [CM])
b. Key and Key profile for the ISK (to the Card Manufacturer [CM])

2.3.1 IC Manufacturer’s Processing Flow

Figure 2-3 depicts the IC Manufacturer’s participation in the production lifecycle.

Platform Developer IC Manufacturer Card Manufacturer

Sends binary Operating Receives binary OS

System to the IC Manufactures chip
Manufacturer

Sends IC information to the Receives IC information

Card Manufacturer from IC Manufacturer

Sends IC to the Card Receives IC

Manufacturer

Sends Initial Supplier Key to Receives ISK from IC

the Card Manufacturer Manufacturer

Figure 2-3 IC Manufacturer’s Processing Flow

2.4 Card Manufacturer

The Card Manufacturer is the entity that manufactures (fabricates) cards to the requirements of the
Card Issuer. This role is principally a materials management role. It is often coupled with the Loader
and Card Enabler roles in the initial production of the cards.

The Actors playing this role will be primarily those entities currently manufacturing cards for the Smart
Card industry, although other entities in different industry sectors may also choose to do so.

The Card Manufacturer has the following responsibilities:

to procure and accept all material components necessary for card manufacturing (i.e., chips,
plastic),
to produce plastic card bodies to the design requirements of the Card Issuer,
to embeds the chips in the card plastic,
to load the card manufacturer initial key(s) for the Issuer Security Domain,
to update the card lifecycle status (GP: OP_READY state refer to GP card spec),
to securely deliver the cards to the Card Issuer (or Card Issuer agents),
to create initial card profiles,
and to generate unique card serial number.
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 12/113

To perform its responsibilities, the Card Manufacturer should be able to:

1. Receive from other actors:

a. IC information (from the IC Manufacturer [IM])
b. Key and Key profile for the ISK (From the IC Manufacturer [IM])

2. Send to other actors:

a. Initial Card Profile (to the Card Issuer [CI])
b. Key and Key profile for the transport key (to the Card Issuer [CI])

2.4.1 Card Manufacturer’s Processing Flow

The Card Manufacturer’s processing flow consists of activities required for embedding the IC into the
card. Figure 2-4 depicts the Card Manufacturer’s participation in the production lifecycle.

IC Manufacturer Card Manufacturer Card Issuer

Generate and send Initial

Receives Initial Supplier
Supplier Key (profile and
Key (profile and value) from
value) to the Card
IC Manufacturer.
Manufacturer

Sends IC information to the Receives IC information

Card Manufacturer from IC Manufacturer
Embeds chip in the card
Generates the Issuer Receives Initial Issuer
Security Domain Initial Keys Security Domain Keys
and load them and sends (profile and value) and
(profile and value) them to sends them to card enabler
the Card Issuer

Changes the status of the

card to OP_READY

Creates initial Card Profile Receives initial Card Profile

and sends it to card enabler

Figure 2-4 Card Embedding Processing Flow

2.5 Card Enabler

The Card Enabler performs pre-personalization functions, specifically the loading of the initial Issuer
and the Application Provider Security Domain keys and personalizing the Issuer’s Security Domain
with Issuer specific data. Should a card support delegated management, the Card Enabler would
also load the Issuer’s token verification and receipt generation keys on the card. The token
verification key is used to verify the authenticity of any third party applications Extradition, Load and
Install tokens before delegated management Extradition, Load or Install is permitted. The receipt
generation key is used to sign a receipt after a successful delegated management load, install,
extradition or delete

Part of the responsibility for loading any Application Provider Security Domain keys may include
loading DAP verification keys for Security Domains performing DAP or Mandated DAP verification.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

The Card Enabler prepares the platform for subsequent application loading.

The Actors playing this role will be primarily those entities currently providing bureau operations,
including manufacturing, data loading and personalization services, to the Smart Card industry,
although other entities may wish to do this.

The Card Enabler has the following responsibilities:

to securely load the platform keys and/or card keys and Card Issuer specific data to the card,
to securely load the supplementary security domain keys,
to update platform lifecycle status (GP: INITIALIZED state refer to GP card spec),
to update the card profile,
and to securely deliver enabled cards to the Card Issuer.

To perform its responsibilities, Card Enabler should be able to.

1. Receive from other actors:

a. Key and Key profile for Transport Key for the Issuer Security Domain (from Card Issuer
[CI])
b. Key and Key profile for Issuer’s Initial Security Domain Keys (from the Card Issuer [CI])
c. Key and Key profile for Issuer Security Domain Token verification Key and issuing
Receipt Key in case of delegated management (from the Card Issuer [CI])
d. Key and Key profile for Supplementary Security Domain keys (from the Application
Provider [AP])
e. Card Profile (from the Card Issuer [CI])
f. Card issuer specific data (from the Card issuer [CI])

2. Send to other actors:

a. Updated Card Profile or updated elements in card profile (to the Card Issuer [CI])

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

2.5.1 Card Enabler’s Processing Flow

The Card Enabler’s processing flow consists of activities required for enabling the card. Figure 2-5
depicts the Card Enabler’s participation in the production lifecycle.

Card Manufacturer Card Issuer Card Enabler

Sends issuer’s specific data Receives issuer’s specific

to the card enabler data

Receives Initial Transport Receives Initial Transport

Sends Initial Transport Key for
Key for Issuer Security Key for Issuer Security
Issuer Security Domain (profile
Domain (profile and value) Domain (profile and value)
and value)
and sends to the Card
Enabler

Receives Card Profile and

Creates initial Card Profile Receives initial Card Profile updates after initialization of
and sends it to card enabler the issuer’s security domain
and sends it back to the
card issuer

Generates initial issuer’s Receives initial issuer’s

security domain keys and Security Domain keys,
optional Token verification optional Token verification
and Receipt generation and Receipt generation
keys with key profiles and keys with key profiles and
Application Provider sends them to the card loads them to the card
enabler

Generates initial
supplementary security Receives initial
domain keys and optional supplementary Security
DAP verification key with Domain keys and optional
key profiles and sends them DAP verification key with
to the card enabler key profiles and loads them

Having card profile and

initial keys with key profiles,
enables the card by loading
initial keys and turn the card
status to INITIALIZED

Has updated card profile for Sends updated card profile

the enabled card which is in or updated elements of the
INITIALIZED state card profile back to the card
issuer

Figure 2-5 Card Enablement Processing Flow

2.6 Application Owner

The Application Owner defines and maintains the IC Card application specifications.

The Actors playing this role may be Payment Associations, Government Departments or any third
party in any industry sector who wishes to do so.

The Application Owner has the following responsibilities:

to obtain and maintain the registry for an Application Identifier (AID) for the application,
to specify requirements for the development and type approval of the application,
to perform configuration management for the application,
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 15/113

to license the application IPR,

and to securely deliver the application product / specification to the Application Provider.

To perform its responsibilities, the Application Owner should be able to:

1. Receive from other actors:

a. Load File (from the Application Developer [AD])
b. Load File profile (from the Application Developer [AD])
c. Application Profile (from the Application Developer [AD])
d. Application Key Profiles (from the Application Developer [AD])

2. Send to other actors:

a. Load File (to the Application Provider [AP])
b. Load File profile (to the Application Provider [AP])
c. Application Profile (to the Application Provider [AP])
d. Application Key Profiles (to the Application Provider [AP])
e. AID (to the Application Provider [AP])
f. Specification including AID (to the Application Developer [AD])

2.6.1 Application Owner’s Processing Flow

The Application Owner’s processing flow consists of activities required for subcontracting application
development. Figure 2-6 depicts the Application Owner’s participation in the production lifecycle.

Application Developer Application Owner Application Provider

Receives application Sends application

specification including AID specification including AID

Develops application,
application profile, load file
profile and application key
profiles
Receives application profile,
loadfile, loadfile profile, Receives application profile,
Sends application profile, application key profiles, AID loadfile, loadfile profile,
loadfile profile, application and sends them to the application key profiles and
key profiles and load file Application Provider AID

Figure 2-6 Application development Subcontracting Processing Flow

2.7 Application Developer

The Application Developer writes application code.

The Actors playing this role will be primarily software house experts in the language of the target
platform.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

The Application Developer has the following responsibilities:

to develop the application according to the requirements and specifications provided by the
Application Owner,
to securely deliver the completed product to the Application Owner,
to satisfy Type Approval requirements specified by the Application Owner,
and to create and to maintain application related profiles.

To perform its responsibilities, Application Developer should be able to:

1. Receive from other actors:

a. Application Specification and optional AID (from the Application Owner [AO])

2. Send to other actors:

a. Load File (to the Application Owner [AO])
b. Load File profile (to the Application Owner [AO])
c. Application Profile (to the Application Owner [AO])
d. Application Key Profiles (to the Application Owner [AO])

2.7.1 Application Developer’s Processing Flow

Refer to Figure 2-6 for an illustration of the Application Developer’s participation in the production
lifecycle.

2.8 Application Provider

The Application Provider procures the necessary components to load a complete application on to a
card (i.e., application code, application data, application keys and/or certificates, and data belonging
to a specific Cardholder). The Application Provider has a direct business relationship with the
Cardholder and provides a card-based service to that Cardholder.

The Actors playing this role will be primarily traditional Card Issuers, loyalty scheme operators,
government associations or Certificate Authorities managing public key infrastructures, although
other entities in different industry sectors will also do so.

The Application Provider has the following responsibilities:

to define its own application product or card service offering,
to establish the business relationship with the Card Issuer of the card for the target
Cardholder and obtain the necessary authority to load code and data onto the Card Issuer's
card,
to maintain an inventory of or be able to generate application load files for various platforms
and chips,
to securely produce and maintain an inventory of application keys and/or certificates (for
protection of code or insertion into application),
to obtain from the Card Issuer and maintain an inventory of application load tokens,
to establish base policies for application expiry, renewal, update and replacement,
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 17/113

to identify and qualify Cardholders who may use the service,

to contract for services with and securely deliver necessary application components to the
Loader,
to provide an appropriate Cardholder assistance and support infrastructure for provided
applications,
to comply with security policies and procedures set by the Card Issuer,
to operate under appropriate security and quality processes (i.e., accepted industry practices,
guidelines, standards, laws, regulations),
and to make modifications and to maintain scripts, application profiles and load file profiles
under the direction of the Card Issuer.

To perform its responsibilities, the Application Provider should be able to:

1. Receive from other actors:

a. Load File (from the Application Owner [AO])
b. Load File profile (from the Application Owner [AO])
c. Application Profile (from the Application Owner [AO])
d. Application Key Profile (from the Application Owner [AO])
e. AID (from the Application Owner [AO])
f. Logical Card Reference Number CRN (from the Card Issuer [CI])
g. Application data preparation request (from the Card Issuer [CI])
h. Application Audit Data (from the Collator/Decollator [CD])

2. Send to other actors:

a. Load File (to the Card Issuer [CI])
b. Load File profile (to the Card Issuer [CI])
c. Application Profile (to the Card Issuer [CI], Collator/Decollator [CD])
d. Key profiles for application keys (to the Collator/Decollator [CD])
e. Key profiles for application secret data Transport keys (to the Collator/Decollator [CD])
f. Keys (including optional DAP verification key) and key profiles for the Supplementary
Security Domain (to the Card Enabler [CE])
g. Application data per CRN (to the Collator/Decollator [CD])
h. Application install parameter data (to the Card Issuer [CI])
i. AID (to the Card Issuer [CI])

2.8.1 Application Provider’s Processing Flow

The Application Provider’s processing flow consists of activities required for preparing the application
data. Figure 2-7 depicts the Application Provider’s participation in the production lifecycle. For
further illustration of the Application Provider’s role, refer to Figure 2-5, Figure 2-6 and Figure 2-8.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Application Owner Application Provider Card Issuer Collator

Receives AID from

Sends AID Application Owner and Receives AID from
sends it to the Card Issuer Application Provider

Sends application profile, Receives application profile,

load file profile, application loadfile profile, application
key profile and load file key profile and load file

Prepares load file

application’s install
parameters data

Receives and sends

Sends application profile, Receives application profile, application profile, loadfile
load file profile, load file, loadfile profile, load file, profile, load file,
application’s install application’s install application’s install
parameters data to the Card parameters data and sends parameters data to the
Issuer for load and/or install to the Collator Loader for load and/or
process under Issuer’s install process under
Security domain Issuer’s Security domain

Receives the CRN for which Sends CRN to the application

application data should be provider along with data
prepared and sent to the preparation request for this CRN
Collator for collation

Having list of CRNs,

application provider Receives application data
prepares data and send it to per CRN for data collation
the Collator

Sends key profiles for

application keys and Receives key profile and
application secret data sends it to the Loader
transport keys to the collator

Sends application profile Receives application profile

to the collator and sends it to the loader

Receives the audit trails

from Loader per CRN

Performs decollation of
audit trails for card issuer
and application providers

Receives the decollated Sends the decollated audit

audit trail trail for the Application
Provider

Figure 2-7 Application and Application Data Preparation Processing Flow

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

2.9 Card Issuer

The Card Issuer holds ultimate responsibility for the GlobalPlatform card. A Card Issuer may be the
only authority that allows load, install, delete, extradition or personalization of applications or the Card
Issuer may delegate load, install, extradition or personalization of the applications to a third party
such as an Application Provider.

The Card Issuer issues cards to the Cardholders. The Card Issuer is responsible for securely
managing all the pre-issuance production processes culminating in a card specifically prepared for a
Cardholder, and for many post-issuance processes, including final decommissioning of a card.

The Card Issuer determines a portfolio of applications to be supported and offered to its card base.
The Issuer manages authorization of applications permitted to reside on its cards.

The Actors playing this role could be Financial Institutions, Transport Operators, Telecommunications
Companies, University Campuses or Government bodies.

The Card Issuer has the following responsibilities:

to develop the card product profile,
to choose the platform and application technologies,
to design card layout (graphical data),
to choose other actors and govern the relationship with those actors,
to control inventory of the cards, including card orders from the Card Manufacturers and
distribution to the Cardholders,
to control the inventory of supported applications versus different Platform/hardware card
combinations,
to control the data, keys, and/or certificates necessary for enabling cards with card unique
information and contract for services with the Card Enabler,
to maintain an inventory of platform related keys and/or certificates,
to maintain an inventory and provide to the Application Providers the necessary application
load, install or extradition tokens,
to maintain the CIN for each Cardholder,
to manage security policies and procedures governing the relationships between, and the
internal practices of, all actors (i.e., logical access control policies, procedures to ensure
appropriate segregation between the IC Manufacturer, the Card Manufacturer and the
Application Provider security domains, and the Application Provider and the Issuer security
domains),
to govern the usage of profiles and scripts for purposes of load, personalization, delete,
extradition and update operations),
to maintain the issued card base policies for card and application expiry, renewal, update and
replacement both by Cardholder and by type of card issued,
to establish the policies and operating rules governing application loading and deleting,
to control identification, qualification and validation of Cardholders,
to control the supply of cards and applications for Cardholders,
and to provide the appropriate Cardholder assistance and support infrastructure.
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 20/113

To perform its responsibilities, the Card Issuer should be able to:

1. Receive from other actors:

a. Load File (from the Application Provider [AP])
b. Load File profile (from the Application Provider [AP])
c. Application Profile (from the Application Provider [AP])
d. Initial Card profile (from the Card Manufacturer [CM])
e. Card profile changes (from the Card Enabler [CE])
f. Application install parameter data (from the Application Provider [AP])
g. AID (from the Application Provider [AP])
h. Batch and card audit trail and data in card profile format (from the Collator/Decollator
[CD])
i. Load, install, extradition and delete receipts for delegated management (From the
Application Provider [AP])

2. Send to other actors:

a. CRN (to the Application Provider [AP])
b. Card Profile (to the Card Enabler [CE] and to the Collator/Decollator [CD])
c. Load File (to the Collator/Decollator [CD])
d. Load File profile (to the Collator/Decollator [CD])
e. Application Profile (to the Collator/Decollator [CD])
f. Application Profile for Platform application (to the Collator/Decollator [CD])
g. Key profiles for Transport Keys (to the Card Enabler [CE])
h. Key profiles for Security Domain Keys (to the Card Enabler [CE] and to the
Collator/Decollator [CD]),
i. Key profiles for the Card Issuer secret data Transport Keys (to the Collator/Decollator
[CD])
j. Batch and card customization data per CRN (to the Collator/Decollator [CD])
k. Application install parameter data (to the Collator/Decollator [CD])
l. Card Issuer Specific data (to the Card Enabler [CE])
m. PIN (to Card Holder [CH])
n. Load, install and extradition tokens for delegated management (to the Application
Provider [AP])

2.9.1 Card Issuer’s Processing Flow

The Car Issuer’s processing flow consists of activities required for card customization. Figure 2-8
depicts the Card Issuer’s participation in the production lifecycle.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Application Provider Card Issuer Collator Loader

Receives the card profile for

Sends the card profile Receives the card profile load and/or install application
and/or personalization of the
applications
Sends the platform Receives the platform Receives platform application
application profile application profile profile for load and/or install
and/or personalization of the
applications
Sends application profile, Receives application Receives application Receives application
loadfile profile, load file, profile, loadfile profile, load profile, loadfile profile, load profile, loadfile profile, load
application’s install para file, application’s install file, application’s install file, application’s install
meters data to the Card para meters data and para meters data and para meters data for load
Issuer for load and/or sends to the Collator for sends to the Loader for and/or install process
install process under load and/or install process load and/or install process under Issuer’s Security
Issuer’s Security domain under Issuer’s Security under Issuer’s Security domain
domain domain

Receives the CRNs for Sends CRN to the

which application data application provider along
should be prepared and with data preparation
sent to the Collator for request for this CRN
collation

Key profiles for Card Key profiles for Card Key profiles for Card
Issuer secret data Issuer secret data Issuer secret data
Transport Keys Transport Keys Transport Keys
Sends Job/collator Receives Job/collator
Configuration data per Configuration data per
CRN for data collation CRN for data collation
Having list of CRNs,
application provider Receives application data
prepares data and sends it per CRN for data collation
to the Collator
Receives key profile and Receives key profile for
Sends key profiles for sends it to the application application secret data
application secret data loader transport keys personalization
transport keys to the
collator
Receives application Receives application
Sends application profile profile and sends it to the profile for personalization
to the collator application loader

Having job/collator
configuration data and
application data per CRN,
the Collator performs the
collation for the Loader

Sends the collated data to Receives application data.

the Loader Having all the elements
the Loader performs card
customization (load and/or
install and/or
Receives the audit trails personalization) and
from application loader per returns the audit trails
CRN
Performs decollation of
audit trails for card issuer
and application providers

Receives the updated card Receives the updated card Sends updated card profile
profile or updated element profile or updated element or updated element of the
of the card profile to of the card profile and card profile to the data
update the card profile to sends it to the card issuer decollator
be stored

Receives the decollated Sends the decollated audit

batch/card audit trail trail for the card issuer

Receives the decollated Sends the decollated audit

application audit trail trail for the application
providers

Figure 2-8 Card Customization Processing Flow

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

2.10 Collator/Decollator
An Application Provider may generate personalization data for one or more applications or the
request could be sent to individual Application Providers. The result from the personalization request
is sent to the Collator/Decollator. The Collator/Decollator performs the collation of multi-application
personalization data for each Cardholder into a single data stream for processing by a Loader. The
Collator/Decollator could perform the reverse communications by sending information that was
produced by the Loader to the Application Provider. This is called Demodulation performed by the
Collator/Decollator.

The Collator/Decollator is responsible for ensuring that all the data pertaining to the suite of
applications offered to the Cardholder reaches the correct card. The Collator/Decollator achieves this
by linking the Issuer and all Application Provider data using the Logical Card Reference Number
(CRN).

While the functionality of the Collator/Decollator remains the same, there are a variety of different
implementation scenarios such as the Collator/Decollator being part of the Loader/Personalization
system, or being part of the Issuer/SCMS, or in cases where extreme privacy is required, the
Collator/Decollator may be a third party.

After personalization, the Collator/Decollator performs the decollation function to return information to
the Issuer and the appropriate Application Providers about the results of the personalization process.
The return data may also contain any exception information or error messages. There are also a
variety of implementations regardless of the location of the decollation function. The decollation
function may take place in a Loader/Personalization System, or in an Issuer/SCMS location, or by an
Application Provider. In cases where extreme privacy is required, the decollation function may be
done by a third party.

The Actors playing this role will be primarily those entities that provide the interface to the Loader and
are responsible for the order. It is also possible for specific implementations to combine the
Collator/Decollator role with other roles or even divide these responsibilities among multiple roles.

The Collator/Decollator has the following responsibilities:

Interface with the Card Issuer to obtain the parameters for a specific issuance job, including:
Card type identifier
List of CRNs for each card to be issued
List of application AIDs for each CRN, for which application personalization data must be
prepared
Job and environment data for Personalization Bureau usage
Potentially collate the load file and application profile for each application.
Interface with one or more Application Providers (Data Generation responsibility) for receipt
of that Provider's application personalization data and personalization scripts for each CRN.
Interface with the Loader to transmit single collated data stream for processing.
Interface with the Loader to receive audit return data. Decollation is a process of sending
data out to:
the Application Providers (application’s audit data),
and the Card Issuer (configuration audit data).

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Ensure enforcement of the Card Issuer security policies for transmission of data.

To perform its responsibilities, the Collator/Decollator should be able to:

1. Receive from other actors:

a. Card Profile (from the Card Issuer [CI])
b. Application Install Parameter Data (from the Card Issuer [CI])
c. Job/Collator configuration Data per CRN (from the Card Issuer [CI])
d. Application Data (from the Application Provider [AP])
e. Load File (from the Card Issuer [CI])
f. Load File profile (from the Card Issuer [CI])
g. Application Profile (from the Application Provider [AP] and the Card Issuer [CI])
h. Key profiles for application keys (Application Provider [AP])
i. Key profiles for application secret data Transport keys (Application Provider [AP])
j. Load, Install and extradition Tokens (from the Application Provider [AP])
k. Key profiles for Security Domain keys (from the Card Issuer [CI])
l. Key profiles for the Card Issuer secret data Transport keys (from the Card Issuer [CI])
m. Updated Card Profile or updated elements in card profile format (from the Loader [LO])
n. Audit trails (from the Loader [LO])
o. Load, Install, extradition and delete Receipts (from the Loader [LO])

2. Send to other actors:

a. Card Profile (to the Loader [LO])
b. Load File (to the Loader [LO])
c. Load File profile (to the Loader [LO])
d. Application Profile (to the Loader [LO])
e. Key profiles (to the Loader [LO])
f. Application install parameter data (to the Loader [LO])
g. Card Customization Data (to the Loader [LO])
h. Load, Install and extradition Token (to the Loader [LO])
i. Audit trail for Application Provider (to the Application Provider [AP])
j. Updated Card Profile or card profile changes (to the Card Issuer [CI])
k. Audit trail for the Card Issuer (to the Card Issuer [CI])
l. Load, Install, extradition and delete Receipts ((to the Application Provider [AP])

2.10.1 Collator/Decollator’s Processing Flow

Refer to Figure 2-9 for an illustration of the Collator/Decollator’s participation in the production
lifecycle.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

2.11 Loader
The Loader loads Card Issuer specific cards with applications and/or personalization/customization
data according to the instructions of the Application Provider [complying with security policies and
procedures set by the Card Issuer]. It may also place the final Security Domains keys on the card. It
is important to note that the roles and even the Actors themselves may differ for the initial batch
loading of applications and the loading of applications post issuance.

The Actors playing this role will be primarily those entities currently providing (batch) bureau
operations, including data loading, personalization and customization services, to the Smart Card
industry, although other entities may wish to do this. The “Loader” and the “Personalizer” represent
the same entity.

It is likely that the remote loading of applications and customer data over new networks (such as the
Internet) will lead to a number of new (online) Actors performing this role.

The Loader has the following responsibilities:

to securely receive application code, application keys and/or certificates, application tokens
and Cardholder specific personalization data from the Application Provider,
to prepare application code, application keys and/or certificates, application tokens and
personalization data to a format necessary for loading to an Open Platform card,
to provide software, firmware and / or network infrastructure necessary to load the above to a
specific Cardholder card,
to delete application code, keys/certificates and personalization data for specific Cardholders,
to securely deliver mechanisms for the loading, installing, extradition and deletion process
(e.g., remote communication procedures),
to undertake the entire application personalization process including writing of data to
magnetic stripe and embossing where required,
to load the supplementary security domain,
to securely load security domain specific keys and data to the card,
and to process load and personalization scripts.

To perform its responsibilities, the Loader should be able to:

1. Receive from other actors:

a. Card Profile (from the Collator/Decollator [CD])
b. Load File (from the Collator/Decollator [CD])
c. Load File Profile (from the Collator/Decollator [CD])
d. Application Profile (from the Collator/Decollator [CD])
e. Platform Application Profile (from the Collator/Decollator [CD])
f. Keys and Key profiles (from the Collator/Decollator [CD])
g. Card Customization Data (from the Collator/Decollator [CD])
h. Application install parameter data (from the Collator/Decollator [CD])
i. Load, Install and extradition Token (from the Collator/Decollator [CD])

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

2. Send to other actors:

a. Batch/Card Audit Trail (to the Collator/Decollator [CD])
b. Updated Card Profile or Card Profile Changes (to the Collator/Decollator [CD])
c. Load, Install, extradition and delete Receipt (to the Collator/Decollator [CD])
d. Card (to Card Holder [CH])

2.11.1 Loader’s Processing Flow

Figure 2-9 depicts Loader’s participation in the production lifecycle.

Collator Loader Card Holder

Receives application profile,

Sends application profile, load file, load file profile,
loadfile profile, load file, card profile, card
card profile, card customization data, install
customization data, install parameters data to load
parameters data and/or install and/or
personalize the card

Sends Issuer security Receives Issuer security

domain and issuer secret domain and issuer secret
data keys and key profiles data keys and key profiles

Sends application keys and Receives application keys

application secret data keys and application secret data
and key profiles keys and key profiles

Performs card customization

Updates card profile

Receives audit trails for Sends audit trails

decollation

Receives the updated card Sends updated card profile

profile or card profile or card profile changes
changes and sends to the
card issuer

Sends the card to the Receives the card

cardholder

Figure 2-9 Card Customizing Processing Flow

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

2.12 Cardholder
The Cardholder is the entity that receives the card.

The Cardholder is the user of the card/chip that interacts with the contents on the card/chip. A
Cardholder maintains the contents of the chip with the authorization of the Card Issuer.

The Actors playing this role will be the target customers of the Card Issuers and Application
Providers.

The Cardholder has the following responsibilities:

to obtain a card from the Card Issuer; to use the card in accordance with terms & conditions
of the Card Issuer and relevant Application Provider(s); to request and obtain
additional/replacement applications from an Application Provider.

To perform its responsibilities, Card Holder should be able to:

1. Receive from other actors:

a. Card (from the Loader [LO])
b. PIN, if any (from the Card Issuer [CI], Application Provider [AP])

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

3. Data Exchange Matrix

TO Card Card IC Platform Card Application Application Application Collator/Decollator Loader Card
Issuer Manufacturer Manufact. Develop Enabler Develop Owner Provider [CD] [LO] Holder
From [CI] [CM] [IM] [PD] [CE] [AD] [AO] [AP] [CH]
Card -Card Issuer -CRN (data -Card profile -PIN
Issuer Specific Data prep request) -Load File
[CI] -Card profile -Load File profile
-Key Profiles for -Application Profile
Security Domain -Issuer Security Domain App. Profile
keys -Key profiles for Security Domain
-Key profile for Keys
TK -Key profiles for secret data TK
-Job/collator config
-Application install parameter data
Card Manufacturer -Initial Card
[CM] profile
-Key profile for
TK
IC -Key profile for
Manufacturer ISK
[IM] -IC information
Platform -Binary
Developer OS
[PD]
Platform -Platform
Spec Owner Spec.
[PS]
Card -Updated card
Enabler profile/card
[CE] profile changes
Application -Load File
Develop -Load File
[AD] profile
-App Profile
-App Key
Profiles
Application - -Load File
Owner Specification -Load File
[AO] including AID profile
-App Profile
-App Key
Profiles
-AID
Application -Load File -Keys (including -Application Profile -PIN
Provider -Load File optional DAP -Key profiles for Application Keys
[AP] profile verification key) -Key profiles for application secret
-Application with key profiles data TK
Profile for -Application data per CRN
-Application Supplementary - Supplementary Security Domain
install Security Domain profile and Key Profiles for SD keys
parameter data
-AID
Collator/ -Batch/Card -Application -Card profile
Decollator audit trail audit trail -Card customization
[CD] -Updated card data
profile/card -Load File
profile changes -Load File profile
-Application profile
-Platform App profile
-Keys and Key
profiles
-Application install
parameters data
Loader -Batch/Card audit trail -Card
[LO] -Card profile/card profile changes

Table 3-1 Data Exchange Matrix

Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 28/113

3.1 Card Issuer Data Exchange

3.1.1 Card Issuer [CI] to Card Enabler [CE]

Table 3-2 summarizes the messages exchanged from the Card Issuer to the Card Enabler.
Exchange ID Message Content
CI.CE.1 Card Issuer Specific Data
CI.CE.2 Card profile
CI.CE.3 Key Profiles for Security Domain
keys
CI.CE.4 Key profile for TK
Table 3-2 Card Issuer [CI] to Card Enabler [CE]

3.1.2 Card Issuer [CI] to Application Provider [AP]

Table 3-3 summarizes the message exchanged from the Card Issuer to the Application Provider.
Exchange ID Message Content
CI.AP.1 CRN (Data prep. Request)
Table 3-3 Card Issuer [CI] to Application Provider [AP]

3.1.3 Card Issuer [CI] to Collator/Decollator [CD]

Table 3-4 summarizes the messages exchanged from the Card Issuer to the Collator/Decollator.
Exchange ID Message Content
CI.CD.1 Card profile
CI.CD.2 Load File
CI.CD.3 Load File profile
CI.CD.4 Application Profile
CI.CD.5 Key profiles for Security Domain
Keys
CI.CD.6 Key profiles for secret data TK
CI.CD.7 Job/Collator configuration data
CI.CD.8 Application install parameters data
CI.CD.9 Platform Application Profile
Table 3-4 Card Issuer [CI] to Collator/Decollator [CD]

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

3.2 Card Manufacturer Data Exchange

3.2.1 Card Manufacturer [CM] to Card Issuer [CI]

Table 3-5 summarizes the messages exchanged from the Card Manufacturer to the Card Issuer.
Exchange ID Message Content
CM.CI.1 Initial Card profile
CM.CI.2 Key profile for TK
Table 3-5 Card Manufacturer [CM] to Card Issuer [CI]

3.3 IC Manufacturer Data Exchange

3.3.1 IC Manufacturer [IM] to Card Manufacturer [CM]

Table 3-6 summarizes the messages exchanged from the IC Manufacturer to the Card Manufacturer.
Exchange Message Content
ID
IM.CM.1 Key profile for ISK
IM.CM.2 IC information
Table 3-6 IC Manufacturer [IM] to Card Manufacturer [CM]

3.4 Platform Developer Data Exchange

3.4.1 Platform Developer [PD] to IC Manufacturer [IM]

Table 3-7 summarizes the message exchanged from the Platform Developer to the IC Manufacturer.
Exchange ID Message Content
PD.IM.1 Binary Operating System
Table 3-7 Platform Developer [PD] to IC Manufacturer [IM]

3.5 Platform Specification Owner Data Exchange

3.5.1 Platform Specification Owner [PS] to Platform Developer [PD]

Table 3-8 summarizes the message exchanged from the Platform Specification Owner to the
Platform Developer.
Exchange ID Message Content
PS.PD.1 Platform Specification
Table 3-8 Platform Specification Owner [PS] to Platform Developer [PD]

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

3.6 Card Enabler Data Exchange

3.6.1 Card Enabler [CE] to Card Issuer [CI]

Table 3-9 summarizes the message exchanged from the Card Enabler to the Card Issuer.
Exchange ID Message Content
CE.CI.1 Updated Card Profile
Table 3-9 Card Enabler [CE] to Card Issuer [CI]

3.7 Application Developer Data Exchange

3.7.1 Application Developer [AD] to Application Owner [AO]

Table 3-10 summarizes the messages exchanged from the Application Developer to the Application
Owner.
Exchange ID Message Content
AD.AO.1 Load File
AD.AO.2 Load File profile
AD.AO.3 Application Profile
AD.AO.4 Application Key Profiles
Table 3-10 Application Developer [AD] to Application Owner [AO]

3.8 Application Owner Data Exchange

3.8.1 Application Owner [AO] to Application Developer [AD]

Table 3-11 summarizes the message exchanged from the Application Owner to the Application
Developer.
Exchange ID Message Content
AO.AD.1 Specification including AID
Table 3-11 Application Owner [AO] to Application Developer [AD]

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

3.8.2 Application Owner [AO] to Application Provider [AP]

Table 3-12 summarizes the messages exchanged from the Application Owner to the Application
Provider.
Exchange ID Message Content
AO.AP.1 Load File
AO.AP.2 Load File profile
AO.AP.3 Application Profile
AO.AP.4 AID
AO.AP.5 Application Key Profile
Table 3-12 Application Owner [8] to Application Provider [9]

3.9 Application Provider Data Exchange

3.9.1 Application Provider [AP] to Card Issuer [CI]

Table 3-13 summarizes the messages exchanged from the Application Provider to the Card Issuer.
Exchange ID Message Content
AP.CI.1 Load File
AP.CI.2 Load File Profile
AP.CI.3 Application Profile
AP.CI.4 Application Install Parameters Data
AP.CI.5 AID
Table 3-13 Application Provider [AP] to Card Issuer [CI]

3.9.2 Application Provider [AP] to Card Enabler [CE]

Table 3-13 summarizes the messages exchanged from the Application Provider to the Card Enabler.
Exchange ID Message Content
AP.CE.1 Key Profiles for Security Domain
keys
Table 3-14 Application Provider [AP] to Card Enabler [CE]

3.9.3 Table Application Provider [AP] to Collator/Decollator [CD]

Table 3-15 summarizes the messages exchanged from the Application Provider to the
Collator/Decollator.
Exchange ID Message Content
AP.CD.1 Application Profile
AP.CD.2 Key profiles for Application Keys
AP.CD.3 Key profiles for application secret data
TK
AP.CD.4 Application data per CRN
Table 3-15 Application Provider [AP] to Collator/Decollator [CD]
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 32/113

3.10 Collator/Decollator Data Exchange

3.10.1 Collator/Decollator [CD] to Card Issuer [CI]

Table 3-16 summarizes the messages exchanged from the Collator/Decollator to the Card Issuer.
Exchange ID Message Content
CD.CI.1 Batch/Card Audit Trail
CD.CI.2 Updated Card Profile
Table 3-16 Collator/Decollator [CD] to Card Issuer [CI]

3.10.2 Collator/Decollator [CD] to Application Provider [AP]

Table 3-17 summarizes the message exchanged from the Collator/Decollator to the Application
Provider.
Exchange ID Message Content
CD.AP.1 Application Audit Trail
Table 3-17 Collator/Decollator [CD] to Application Provider [AP]

3.10.3 Collator/Decollator [CD] to Loader [LO]

Table 3-18 summarizes the messages exchanged from the Collator/Decollator to the Loader.
Exchange ID Message Content
CD.LO.1 Card Profile
CD.LO.2 Batch/Card Customization Data
CD.LO.3 Load File
CD.LO.4 Load File profile
CD.LO.5 Application Profile
CD.LO.6 Keys and Key Profiles
CD.LO.7 Application Install Parameters Data
CD.LO.8 Platform Application Profile
Table 3-18 Collator/Decollator [CD] to Loader [LO]

3.11 Loader Data Exchange

3.11.1 Loader [LO] to Collator/Decollator [CD]

Table 3-19 summarizes the messages exchanged from the Loader to the Collator/Decollator.
Exchange ID Message Content
LO.CD.1 Batch/Card Audit Trail
LO.CD.2 Updated Card Profile
Table 3-19 Loader [LO] to Collator/Decollator [CD]

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

4. Message Categorization
Table 4-1 categorizes the messages summarized and described in the previous sections under
logical groupings containing messages of similar type. Aside from messages which typically only
occur once in a one-time information exchange, the bulk of the messages can either be categorized
as messages used in exchanging profiles and messages used to facilitate card customization
processes.

Message Message Type Exchange ID Message Content

Category
One time CI.CE.1 Card Issuer Specific Data
Information AO.AD.1 Specification including AID
exchange IM.CM.2 IC information
PD.IM.1 Binary Operating System
PS.PD.1 Platform Specification
Profile
Card Profile CM.CI.1 Initial Card profile
Exchange
exchange CI.CE.2 Card profile
CI.CD.1 Card profile
CD.LO.1 Card Profile
CE.CI.1 Updated Card Profile
LO.CD.2 Updated Card Profile
CD.CI.2 Updated Card Profile
Load File CI.CD.2 Load File
exchange AD.AO.1 Load File
AO.AP.1 Load File
AP.CI.1 Load File
CD.LO.3 Load File
Load File Profile CI.CD.3 Load File profile
exchange AD.AO.2 Load File profile
AO.AP.2 Load File profile
AP.CI.2 Load File profile
CD.LO.4 Load File profile
Application CI.CD.4 Application Profile
Profile exchange AD.AO.3 Application Profile
AO.AP.3 Application Profile
AP.CI.3 Application Profile
AP.CD.1 Application Profile
CD.LO.5 Application Profile
CI.CD.9 Platform Application Profile
CD.LO.8 Platform Application Profile
Platform Key CI.CE.3 Key Profiles for Security Domain keys
Profile exchange CI.CD.5 Key profiles for Security Domain Keys
Application Key AP.CD.2 Key profiles for Application Keys
Profile exchange AP.CE.1 Key profiles for Security Domain Keys
AD.AO.3 Key profiles for Application Keys
AO.AP.5 Key profiles for Application Keys
Transport Key AP.CD.3 Key profiles for application secret data TK
Profile exchange CI.CD.6 Key profiles for secret data TK
CM.CI.2 Key profile for TK

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Message Message Type Exchange ID Message Content

Category
IM.CM.1 Key profile for ISK
CI.CE.4 Key profile for TK
CD.LO.6 Key Profiles
Card Install Parameter CI.CD.8 Application install parameter data
Customization exchange AP.CI.4 Application Install Parameters Data
Exchange CD.LO.7 Application Install Parameters Data
AID exchange AO.AP.4 AID
AP.CI.5 AID
CRN exchange CI.AP.1 CRN
Customization CI.CD.7 Job/Collator configuration Data
data exchange AP.CD.4 Application data per CRN
CD.LO.2 Card Customization Data
Return Audit LO.CD.1 Batch/Card Audit Trail
Trail exchange CD.CI.1 Batch/Card Audit Trail for Card Issuer
CD.AP.1 Application Audit Trail
Table 4-1 Message Categories

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

5. GlobalPlatform Message Structure

The GPMessage is the GlobalPlatform message envelope. It is composed of the GPHeader and
the GPBody elements, the latter incorporates different types of messages.

Figure 5-1 illustrates the GPMessage.

Figure 5-1 GPMessage XML Diagram

Name Description Data Type Encoding No.

None

Table 5-1 GPMessage Attributes

5.1 Namespaces
In order to allow modularity, evolution and seamless integration of the Global Platform messaging in
complex systems, all messages should be expressed in a specific conventional namespace.

GlobalPlatform XML files should comply to [W3C NAMESPACES].

Namespaces identifiers for GlobalPlatform Messaging Specification respects the following layout:

http://namespaces.globalplatform.org/systems-messaging/[VERSION]

http://namespaces.globalplatform.org/systems-messaging/[VERSION]/[NAMESPACE]

The latter layout to be used if the namespace identification must be more precise than the version of
the specifications.

Therefore, the namespace that defines elements used in the XML messages described in this
document is given the following identifier:

http://namespaces.globalplatform.org/systems-messaging/1.0.0

Therefore, XML messages that comply with this specification must refer to this URI.
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 36/113

5.2 Data Types and String Encoding

The data types in this specification are defined to be consistent with the data types defined in the
GlobalPlatform Systems Profiles Specification and the GlobalPlatform Systems Scripting Language
Specification.

Table 5-2 provides an overview of the abstract data types used throughout this specification
and their text encoding in XML.

Name Description
The value is a sequence of characters. The value is encoded in XML as a
sequence of characters. Characters may be ‘escaped’ using XML entities.
The value “<=” is encoded in XML as follows:
String <=

Separate attributes may indicate additional encodings. See Table 5-3 for a list
of supported text encodings for scripting language ByteString objects.
The value is an integer number. The value is encoded in XML as a decimal or
hexadecimal sequence of characters. Leading zeroes may be added or
omitted. When a hexadecimal encoding is used, the encoding is pre-fixed with
0x. At the data type level a value does not assume a particular size of an
encoding. Therefore, a negative number cannot be encoded in text using twos-
Integer complement notation, a separate sign character must be included.
The value -12345 can be encoded in XML as follows:
-12345
-000012345
-0x3039
-0x00003039
The value is a Boolean true or false. The value is encoded in XML as a literal
text:
true
false
Boolean
By default, if an attribute is not provided, then it is assumed to have a value of
false for purposes of populating the attribute value, unless otherwise stated in
the specification (notably regarding the MandatoryAudit attribute for
DataElement element).

Table 5-2 Data Types

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Encoding Description
Each byte is encoded as two hexadecimal digits with optional white space. When
a string is decoded white space is accepted. When a string is encoded it is up to
the environment whether white space is inserted or not. Alphabetic characters
may be uppercase or lowercase.
HEX The hex value { 0xab, 0x34, 0x56 } may be encoded as follows:
ab3456
AB 34 56
Ab34 56
ab 3456

Each byte is encoded as a single extended ASCII character. No conversions are

to occur (i.e., no new-line to CRLF conversion).
ASCII
The value {0x47, 0x70, 0x21}:
Gp!

Table 5-3 String Encodings for String Data Type

5.3 XML Schema References

The XML schema refers to the XML schemas defined in the following specifications and
recommendations:

• ds: W3C XML-Signature Syntax and Processing, W3C Recommendation

• gpm: GlobalPlatform Messaging Specification

• gpp: GlobalPlatform Systems Profiles Specification

• xsd: Extensible Markup Language (XML) 1.0, W3C Recommendation

5.4 Encryption XML

The entire message or any part of the message could be encrypted according to the W3C
XML-Encryption Syntax and Processing. However, it requires the mutual pre-agreement between the
sender and the receiver of the message.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

6. Message Header
The GPHeader facilitates the automatic reception of the message and recognition of the sender as
well as the automation of a log to track the reception of the messages. An optional Signature
element allows ensuring the integrity of the message. The type attribute within GBHeader
facilitates parsing of the XML when only one type of message is to be exchanged. If the message
contains messages of different types, then the type attribute is specified as MIXED.

Figure 6-1 illustrates GPHeader.

Figure 6-1 GPHeader XML Diagram

Name Description Data Type Encoding No.

The TransactionID attribute contains

TransactionID String ASCII 1
the unique identifier for the message.
This attribute contains an OID that
identifies the sender of the message.

For example, if the sender is

Sender specified as GlobalPlatform, this String HEX 1
attribute is specified as
2A864886FC6B which
corresponds to the OID {
globalplatform }.
This attribute contains an OID that
identifies the receiver of the
message.

For example, if the receiver is

Destination String HEX 1
specified as GlobalPlatform, this
attribute is specified as
2A864886FC6B which
corresponds to the OID {
globalplatform }.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

Description of the type of the

message.

Valid types are:

AP Application profile
CP Card profile
CP_CHANGES Card profile changes
KP Key profile
KP_EXCHANGES
Key exchange
LFP Load File profile
PROFILE_REQUEST
Profile request
BATCH_CARD_CUSTOMIZATION
Customization data
for a batch of cards
CARD_CUSTOMIZATION
Customization data
for a card
DATA_PREPARATION_REQUEST
Request data *See
Type preparation for a String description 1
given card column
APP_DATA_NOTIFICATION
Personalization data
provided for a given
card
BATCH_AUDIT_TRAIL
Audit trail for batch of
cards
CARD_AUDIT_TRAIL
Audit trail for a given
card
APPLICATION_AUDIT_TRAIL
Audit trail for a given
application for a card
or a batch of cards
ERROR Error notification
MIXED GPBody contains
at least two different
types of messages

Example: CARD_AUDIT_TRAIL

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

Version of messaging specification

conforming to GP versioning.
Version number is x.x.x where each x
is a decimal number. If the version of
the specification has no last x value,
MessageVersion
then version number is x.x.0. String ASCII 1
Example:
1.0.0
1.0.1
1.1.0
1.1.2

Version of messaging specification

errata being used by the message.
Version number is a decimal digit
corresponding to the version of the
errata.
If the attribute is not specified, then
the version of the messaging
specification errata supported is the
latest version.
ErrataVersion If the attribute is specified with a Integer ASCII 0..1
value of zero, then the version of the
messaging specification is the
specification defined in
MessageVersion without any
errata.
Example:
1 defines errata version 0.1
12 defines errata version 0.12
0 defines no errata

Table 6-1 GPHeader Attributes

6.1 Signature XML element

The Signature is an optional element. When present, it allows verifying the integrity of the
message. Signature is defined as per W3C. Signature must be computed over the entire
message. For this purpose, the Reference element of the Signature must reference the
GPMessage. W3C XML-Signature Syntax and Processing provides more information on how to
compute a signature and populate this XML element.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

7. Message body
The GPBody is the element that contains the core of the message. It is composed of one type of
message if the type attribute within GBHeader specifies a type other than MIXED. If MIXED is
specified, the GPBody element will contain at least two different types of messages as represented
by their respective child elements.

Figure 7-1 illustrates the GPBody element and the different types of messages that it could contain.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Figure 7-1 GPBody XML Diagram

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

None

Table 7-1 GPBody Attributes

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

8. Application Profile Message

The AP element represents a single Application Profile based on Application Profile Unique Identifier.
It can be used for Application Profile exchanges CI.CD.4, AD.AO.3, AO.AP.3, AP.CI.3, AP.CD.1,
CD.LO.5, and platform Application Profile exchange messages CI.CD.9 and CD.LO.8.

Figure 8-1 illustrates the AP element.

Figure 8-1 AP XML Diagram

Name Description Data Type Encoding No.

Variable length byte field consisting of

a unique OID.

UniqueID The GlobalPlatform Systems Profiles String HEX 1

Specification provides further
information on how this Unique ID
must be set or updated

Table 8-1 AP Attributes

8.1 ApplicationProfile element

The ApplicationProfile element corresponds to the ApplicationProfile element defined in the
GlobalPlatform Systems Profiles Specification.

8.2 ProfileIdentification element

The ProfileIdentification element is defined in section 9.2.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

9. Card Profile Message

The CP element represents a single Card Profile which can be identified by a Card Profile Unique
Identifier. This could be used for the Card Profile exchange messages CM.CI.1, CI.CE.2, CI.CD.1,
CD.LO.1, CE.CI.1, LO.CD.2 or CD.CI.2. This message basically sends the entire CardProfile
element structure, and may be useful for one-time information exchanges when the receiving party is
not presently aware of the Card Profile for the given Card Profile Unique Identifier or for the given
logical Card Reference Number. If GPBody contains multiple occurrences of CP elements, the
UniqueID attribute of CP allows indexing a specific Card Profile (without the need to parse all the
CardProfile XML elements) within the child elements of this message.

Figure 9-1 illustrates the CP element:

Figure 9-1 CP XML Diagram

Name Description Data Type Encoding No.

Variable length byte field consisting of

variable length OID (as assigned by
ISO for the Card Manufacturer and up
to 119 bytes long) which uniquely
identifies the Card Profile. It is left up
to the Card Manufacturer to ensure
that the OID is unique so that all
UniqueID UniqueID attributes for all the Card String HEX 1
Profiles produced by the Card
Manufacturer are unique.

The GlobalPlatform Systems Profiles

Specification provides further
information on how this Unique ID
should be created.

Table 9-1 CP Attributes

9.1 CardProfile element

CardProfile element corresponds to the Card Profile XML document defined in the GlobalPlatform
Systems Profiles Specification.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

9.2 ProfileIdentification element

The ProfileIdentification element is used for establishing the relationship between the profile
that it is referring to and other related elements such as other profiles or customization data. For
example, a CRN may be used to establish the relationship between all the profiles and the card
customization data for a given card.

Name Description Data Type Encoding No.

Logical Card Reference Number. CRN

is stated as an OID. It identifies a
CRN logical card which includes one or String HEX 0..1
multiple application for a specific
cardholder
Application Identifier per ISO 7816-4.
AID is stated as a hexadecimal value.
AID String HEX 0..1
Example: A123456789AB

Identifier of a key. KeyID is stated as

a hexadecimal value.
KeyID String HEX 0..1
Example: 1234ABFF01

Name of the load file.

LoadFileName String ASCII 0..1
Example: CPSDEMO01.CAP

The label of an identifier other than the

ones defined in this table to be used to
identify the profile by implementation
OtherIDFieldLabel String ASCII 0..1
dependent fields.

Example: SCMS_ID

The Value of the identifier other than

the ones defined in this table to be
used to identify the profile by
implementation dependent fields.
OtherIDFieldValue String HEX 0..1
Example:
If SCMS_ID is the label, this attribute
could contain 2A864886FC6B010203

Table 9-2 ProfileIdentification Attributes

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

10. Card Profile Changes Message

The CPChanges element represents the changes to a Card Profile for a given Card Profile Unique
Identifier. This could be used for the Card Profile exchanges CM.CI.1, CI.CE.2, CI.CD.1, CD.LO.1,
CE.CI.1, LO.CD.2, or CD.CI.2. This message basically sends only a subset of the CardProfile
element structure, and may be useful for information exchanges when the receiving party is presently
aware of the Card Profile for the given Card Profile Unique Identifier or the given Logical Card
Reference Number. It is an optimized message structure for just exchanging changes to a Card
Profile.

Figure 10-1 illustrates the CPChanges element:

Figure 10-1 CPChanges XML Diagram

Name Description Data Type Encoding No.

Variable length byte field consisting of

The GlobalPlatform Systems Profiles

Specification provides further
information on how this Unique ID
should be created.

Table 10-1 CPChanges Attributes

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

10.1 ApplicationInstances element

The ApplicationInstances element corresponds to the Application Instances element defined in
the GlobalPlatform Systems Profiles Specification.

10.2 LoadFileInstances element

The LoadFileInstances element corresponds to the LoadFile Instances element defined in the
GlobalPlatform Systems Profiles Specification.

10.3 CardInfo element

The CardInfo element corresponds to the CardInfo element defined in the GlobalPlatform Systems
Profiles Specification.

10.4 ProfileIdentification element

The ProfileIdentification element is defined in section 9.2.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

11. Key Profile Message

The KP element represents a single Key Profile exchange. It can be used for Platform Key Profile
exchanges CI.CE.3 and CI.CD.5, Application Key Profile exchanges AP.CD.2, AD.AO.3 and AO.AP.5
and Transport Key Profile exchanges AP.CD.3, CI.CD.6, CM.CI.2, IM.CM.1, CI.CE.4 and CD.LO.6.

The KeyExchange message can be used for exchanging the actual key for a Key Profile.

Figure 11-1 illustrates the KP element.

Figure 11-1 KP XML Diagram

Name Description Data Type Encoding No.

Variable length byte field consisting of

a unique OID.

UniqueID The GlobalPlatform Systems Profiles String HEX 1

Specification provides further
information on how this Unique ID
must be set or updated

Table 11-1 KP Attributes

11.1 KeyProfile element

The KeyProfile element corresponds to the KeyProfile element defined in the GlobalPlatform
Systems Profiles Specification.

11.2 ProfileIdentifiction element

The ProfileIdentification element is defined in section 9.2.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

12. Key Exchange Message

For a UniqueID value specified, the KeyExchange element returns the corresponding key value
encrypted under a transport key.

Figure 12-1 illustrates the KeyExchange element:

Figure 12-1 KeyExchange XML Diagram

Name Description Data Type Encoding No.

Variable length byte field consisting of

a unique OID.

UniqueID The GlobalPlatform Systems Profiles String HEX 1

Specification provides further
information on how this Unique ID
must be set.
The actual key value identified by the
UniqueID encrypted under a transport
KeyValue String HEX 1
key identified by the
TransportKeyUniqueID attribute.

Variable length byte field consisting of

a unique OID.

TransportKeyUniqueID The GlobalPlatform Systems Profiles String HEX 1

Specification provides further
information on how this Unique ID
must be set.

Table 12-1 KeyExchange Attributes

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

13. Load File Profile Message

The LFP element represents a single LoadFileProfile exchange based on Load File Profile Unique
ID. It can be used for exchanges CI.CD.2, AD.AO.1, AO.AP.1, AP.CI.1, and CD.LO.3.

Figure 13-1 illustrates the LFP element:

Figure 13-1 LoadFileProfile XML Diagram

Name Description Data Type Encoding No.

Variable length byte field consisting of

a unique OID.

UniqueID The GlobalPlatform Systems Profiles String HEX 1

Specification provides further
information on how this Unique ID
must be set or updated

Table 13-1 LFP Attributes

13.1 LoadFileProfile element

The LoadFileProfile element corresponds to the LoadFileProfile element defined in the
GlobalPlatform Systems Profiles Specification.

13.2 ProfileIdentification element

The ProfileIdentification element is defined in section 9.2.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

14. Profile Request Message

The ProfileRequest element contains one request for a particular profile. It can optionally request
that all the associated profiles need to be returned.

Figure 14-1 illustrates the ProfileRequest message:

Figure 14-1 ProfileRequest XML Diagram

Name Description Data Type Encoding No.

This attribute specifies the type of the

profile.

Example: ASCII
Type AP String *See 1
CP description
CP_CHANGES
KP
KEY_EXCHANGE
LFP

Variable length byte field consisting of

a unique OID.

ProfileUniqueID The GlobalPlatform Systems Profiles String HEX 0..1

Specification provides further
information on how this Unique ID
must be set.
Version of profiles specification
conforming to GP versioning. Version
number is x.x.x where each x is a
decimal number. If the version of the
specification has no last x value, then
ProfileVersion version number is x.x.0. String ASCII 0..1

Example:
1.0.0
1.1.0

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

Indicates if all the associated profiles

need to be returned. For example, if
the request is for a card profile and the
value for this attribute is true, then the
system must return the card profile
AssociateProfiles String Boolean 0..1
along with the application profiles, load
file profiles and key profiles specified
in the card profile.

Default value is false

Table 14-1 ProfileRequest Attributes

14.1 ProfileIdentification element

The ProfileIdentification element is defined in section 9.2.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

15. Application Data Notification Message

The ApplicationDataNotification element represents the actual ICC Data personalization
provided by an Application Provider participant in this transaction. Each Application Provider
participant needs to prepare the personalization data and send it to the collator along with the Batch
ID and the CRN. It can be used for exchange AP.CD.4.

Figure 15-1 illustrates the ApplicationDataNotification element.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Figure 15-1 ApplicationDataNotification XML Diagram

Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 57/113

Name Description Data Type Encoding No.

An ASCII field to identify the batch of

jobs between the SCMS and the
Personalization system. This
information is required by the collator
in order to identify XML messages
coming from different entities but
related to the same batch.

BatchID is required when data

preparation is requested for a batch of
BatchID String ASCII 0..1
cards. BatchID can be omitted when
the data preparation is requested for a
single card as the CRN can be used to
identify personalization data
notification for a single card (i.e., in the
case of post issuance personalization).

Example:
SCMS_ID + Transaction Sequence
Number: 1.2.840.114283.0001

Table 15-1 ApplicationDataNotification Attributes

15.1 ApplicationCommonData element

The ApplicationCommonData provides a set of application data common for all CRNs. This
element is used to prevent the replication of the information for each CRN specified. It encapsulates the
ApplicationData element. The ApplicationCommonData element applies to all CRNs specified
within the ApplicationDataNotification message. The recipient personalization system will need
to take into account the application common data in addition to the application data per CRN. The AID
allows the system to establish the relationship between the common data and specific data per CRN.

Name Description Data Type Encoding No.

None

Table 15-2 ApplicationCommonData Attributes

15.2 ApplicationDataPerCRN element

The ApplicationDataPerCRN element provides the application data specific for a given card
identified by the CRN element. In addition to CRN element, it encapsulates the ApplicationData
element.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

None

Table 15-3 ApplicationDataPerCRN Attributes

15.3 CRN element

The CRN element is used to identify a logical card. The CRN must be communicated to each
application provider responsible to provide the personalization data for that application. The Collator
uses the CRN to collate all the personalization data for each application listed on the
CardConfiguration element and identified by the AID element.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

The logical Card Reference Number

specified by the CRN attribute is an
OID. It must be unique for each
record. It is the responsibility of the
owner of the CRN to ensure the
uniqueness of this number per record.

Example: 2A864886FC6B010203

The following illustrates the example of

OID construction for purposes of the
CRN:

Object identifier value Meaning

{1} ISO
{12} ISO member body
{ 1 2 031 } Azerbaijan
{ 1 2 031 21 } Joe Doe Inc
{ 1 2 031 21 1 } Joe Doe’s Card
Management System
{ 1 2 031 21 1 2 } Joe Doe’s Card
Management System Version 2
{ 1 2 031 21 2 } Joe Doe’s Card
Numbering Scheme. Please use the
recommendations for CRN in the LPIS
CRN since these are used by GEMPlus and String HEX 1
Bell ID. It still remains an OID but
replace Azerbaijan with Country Code ,
John Doe with SCMS ID, John Does
card with Issuer ID etc….

Note that if { 1 2 031 21 } is assigned to

Joe Doe Inc, then lets assume that
internally Joe Doe Inc takes this range
{1 2 031 21 1 3 } as the base of its
CRNs. Joe Doe Inc will can then
provide the CRN numbers in the
following range:

1 2 031 21 1 3 000000000001
1 2 031 21 1 3 999999999999

This is a simplistic illustration of what

could be done. Internal rules to the
organization with respect to CRN
creation may be established, such as:

1 2 031 21 1 3 [RID=5 bytes] [Country

code=2 bytes] [Sequence number = 8
bytes] [and maybe a "1 byte check
value (Modulo 256 (XOR))]

Table 15-4 CRN Attributes

Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 60/113

15.4 ApplicationData element

The ApplicationData element contains the actual card customization data for each application on
the card. The ApplicationData element could be used for the card customization data prepared
using the GlobalPlatform card customization technology (i.e., Profiles and Scripting Language) or any
other alternative means. It can be used as input to a personalization system running GlobalPlatform
card customization technology (i.e., a Scripting Language engine) or using the common
personalization approach defined in the EMV Card Personalization Specification. As the
ApplicationData is used in other XML elements, and in order not to repeat this section and
sections that describe all the children elements of the ApplicationData element, its children
elements are described in the sub-sections of this section. Further messages including the
ApplicationData element will reference this section.

Name Description Data Type Encoding No.

None

Table 15-5 ApplicationData Attributes

15.4.1 AID element

The AID element provides the application identifier as specified in ISO 7816-5. It’s used in the
ApplicationData element to identify a selectable application on the card on which the
ProcessingStep elements will operate. The operation could consist of personalizing the selected
application or using the selected application (i.e., a Security Domain) to load, install or personalize
other applications on the card.

Name Description Data Type Encoding No.

ISO7816 [IS7816-5] Application

Identifier of the application instance.
Hexadecimal value.
AID String HEX 1
Example:
A123456789AB

The order in which the application

must be selected.
Order Integer 1
Example:
01

The expected target state of the

selected application after successful
completion of all of processing steps.
TargetState String ASCII 0..1
Example:
PERSONALIZED

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

The actual state achieved for the

selected application after successful or
unsuccessful completion of the
processing steps for the selected
ReachedState String ASCII 0..1
application.

Example:
INSTALLED

Table 15-6 CRN Attributes

15.4.2 ApplicationProfileUniqueID element

The optional ApplicationProfileUniqueID element, if present, provides the UniqueID of the

application profile corresponding to the application to be selected using the AID element. If the
GlobalPlatform card customization technology (i.e., Profiles and Scripting) is used for card
customization, the ApplicationProfileUniqueID element is required in order to allow the
system to correctly reference the application profile identified by this unique identifier. This
information may not be necessary if another card customization approach such as common
personalization is used.

Name Description Data Type Encoding No.

ApplicationProfileUniqueID UniqueID of the application profile. String HEX N/A

Table 15-7 ApplicationProfileUniqueID Data Type

15.4.3 Data element

The Data element is a placeholder for the actual data. The Data element, when placed in the
ICCData element, is used to carry data to be sent to the IC application. When placed in the
Logdata element, it provides the data to be used to create the log data for audit trails during card
customization. When placed in the PersoDeviceIns element, it contains data to provide
instructions to the personalization system to drive the card customization process.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

When a child of the ICCData element:

1. If GlobalPlatform card
customization technology (i.e.,
Profile and Scripting) is used to
perform the card customization,
DataElement contains the name
of the data element within the
application profile.

Example:
If the DataElement name within
the application profile is “isid“ as
shown in the following example:

then the value of DataElement

within the Data element will be
isid

2. If the common personalization

approach is used, then the value
DataElement of DataElement within the Data String String 1
will be DGI

When a child of the LogData element:

The value is to be defined by the

user.

Example: AccountNumber

When a child of the PersoDeviceIns

element:

If the common personalization

approach is used, then the value of
DataElement within the Data is
specified according to the
GlobalPlatform Guide to common
personalization. <Not exactly sure
what is meant here by this sentence>

Examples:
ORDER, VERCNTL, GROUP, …

If an approach not covered here is

used, then it is to be defined by the
implementation.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

When a child of the ICCData element:

1. If the GlobalPlatform card

customization (i.e., Profiles and
Scripting) is used to process the
card customization, Value
contains the value of the data
element. The data type of the
Value must be consistent with the
Encoding defined for this data
element in the application profile.
In the following example the data
type must be HEX:

<DataElement Name="isid"
External="true"
Type="BYTESTRING" *See
Value Encoding="HEX" …/> String description 1
column
2. If common personalization
approach is used then Value will
be the DGI (including the identifier
and the length). The data type is
always HEX.

When a child of the LogData element:

Value is to be defined by the

implementation.

When a child of the PersoDeviceIns

element:

Value is to be defined by the

implementation.

Table 15-8 Data Attributes

15.4.4 DataSet element

The DataSet element is used to group a set of Data elements which have a logical relationship
with each other. An example of this relationship could be that all Data elements are all encrypted
with the same TransportKey or they should be sent to the IC application within the same
command.

Name Description Data Type Encoding No.

Name Optional name to identify a DataSet. String ASCII 0..1

Table 15-9 DataSet Attributes

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

15.4.5 ICCData element

The ICCData element is a placeholder for the data to be sent to the IC application. The Application
Provider needs to format the data as expected by the personalization process. If the GlobalPlatform
card customization technology (i.e, Profiles and Scripting) is used for personalization, the data
contained in the Data element within ICCData must be consistent with each DataElement element
within the application profile. As the application profile contains all the data element to be used by
different script fragments within the application profile, the ICCData should contain all the external
data required by the ProcessingStep elements. Conversely, if the common personalization
approach is used, then the Data element within ICCData must contain the data expected by the
common personalization process.

Name Description Data Type Encoding No.

None

Table 15-10 ICCData Attributes

15.4.6 LogData element

The LogData element is a placeholder for data to be logged. This is utilized when the Application
Provider needs data from the personalization process to be logged. However, the personalization
device is not aware of what data is required to be logged. Therefore, any data to be logged in
addition to what the device logs by default must be sent to the personalization device in a manner
that indicates that this is log data. To inform the personalization device of application data that must
be logged, the LogData element must be created.

Name Description Data Type Encoding No.

None

Table 15-11 LogData Attributes

15.4.7 PersoDeviceIns element

The PersoDeviceIns element provides special instructions that are created by the Application
Provider during the data preparation process and are used by the personalization device during the
personalization process. The Personalization device instructions are not sent to the IC card. If
Common Personalization is used, this element must be populated according to the GlobalPlatform
Guide to Common Personalization.

Name Description Data Type Encoding No.

None

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Table 15-12 PersoDeviceIns Attributes

15.4.8 ProcessingStep element

The ProcessingStep element provides information on the steps to undertake for card
customization. If Common Personalization is used, this element must be populated according to the
GlobalPlatform Guide to Common Personalization. This section presents an example of how this
element could be used.

Specifically, if the card customization consists of load, install and personalization of an application
either in pre-issuance or post-issuance production stage of the card, the following sequences could
be utilized:
1. The first ApplicationData element should address the AID of the security domain related to the
application(s) to be loaded. The ApplicationProfileUniqueID per card customized must
indicate the unique ID of this security domain application profile where a set of script fragments is
present to perform load and install of the applications. The suggested processing steps would be:

ProcessingStep 1: The script fragment to be executed is GETSTATUS in order to find

out if the Load File is already present on the card or not.
ProcessingStep 2: The script fragment to be executed is LOADFORLOAD in order to
load the Load File into the card.
ProcessingStep 3: The script fragment to be executed is LOADFORINSTALL in order to
create an instance of the application on the card.
2. The subsequent ApplicationData element should reference the AID of the application currently
loaded and installed. The ApplicationProfileUniqueID per card customized must indicate
the unique ID of this application profile (to be personalized) where a set of script fragments is
present to perform personalization of the application. The suggested processing steps would be:

ProcessingStep 1: The script fragment to be executed is PERSONALIZE in order to

personalize the application.

Name Description Data Type Encoding No.

The action to be undertaken by the

personalization device.
Action String ASCII 1
Example:
PERSONALIZE

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

Whether the step is required or

optional. For example, if the
processing step is to install an
application which is already installed,
when this attribute is specified as 01
(required), the personalization device
must delete the already installed ASCII
Requirement instance and install the new instance String *see 1
of the application where optional (00) description
in this case means that no delete and
re-install is necessary.

Example:
00 (optional)
01 (required)

Optional DataSet name in the ICCData

DataSet element to be used to perform this String ASCII 0..1
step.

Table 15-13 ProcessingStep Attributes

15.4.9 Script element

The Script element provides the name of the script fragment within the application profile to be
executed for this processing step.

Name Description Data Type Encoding No.

Implementation defined. For

GlobalPlatform Profiles and Scripting,
Script String ASCII 1
it’s the name of the scripting fragment
within the application profile

Table 15-14 Script Data Type

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

15.4.10 Signature element

The Signature element is an optional element. When present, it allows the verification of the
integrity of the ApplicationDataPerCRN. Signature is defined as per W3C. In order to
ensure that the application data corresponds to the associated CRN, the Signature must be
computed over the ApplicationDataPerCRN. For this, the Reference element of the
Signature must reference the ApplicationDataPerCRN. After collation, the Signature could
be carried over to the Loader in order to keep the original value from the Application Provider. The
entity that verifies the signature must reconstruct the ApplicationDataPerCRN XML element and
computes the signature for verification. If the Signature element is present in the
ApplicationData element within the ApplicationCommonData element, it should be
computed over the ApplicationData element. For this, the Reference element of the
Signature must reference the ApplicationData element. W3C XML-Signature Syntax and
Processing provides more information on how to compute a signature and populate this XML
element.

15.4.11 TransportKey element

The TransportKey element identifies the transport key used for cryptographic operations on the
personalization data during the transportation. The TransportKey element is associated with a
DataSet element. It implies that the value of each Data element within that DataSet is encrypted
using the key identified by the TransportKey. If GlobalPlatform card customization (i.e., Profiles
and Scripting) is utilized, the key profiles used for cryptographic operations on the personalization
data may be defined within the application profile and their unique identifiers passed from the
application provider to the personalization system as part of personalization data. In the latter case,
the TransportKey is not used.

Name Description Data Type Encoding No.

OID used to identify the key to be used

during script processing.

The OID root will not be the same as

that of the Key Profile UniqueID. This
ID attribute value will be universally unique String HEX 0..1
amongst all keys, whereas the
UniqueID of the Key Profile is only
unique for a Key Profile, which, in turn,
may be referenced by more than one
key.
Free text field.

Not necessarily unique amongst all Key

Name String ASCII 0..1
Profiles. This does not have to be the
same name as the Name attribute in the
Key element in the Application Profile.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

Owner of the Key Profile.

The entity controlling and managing the

lifecycle of the key and the data that it
Owner String HEX 0..1
protects. For example, the Owner
attribute could contain the Issuer
Identification Number (IIN) of the key
owner.
Version of the key.

The Version attribute is provided to

support legacy systems using Key
Version String HEX 0..1
Name & Key Version. In the cases
where it is used, it is a hexadecimal
value representation of the numeric
value of the key version.
Algorithm used with the Transport Key
when exporting a key.
ASCII
Algorithm Valid values are: String *see 0..1
description
CBC
ECB

If present, this attribute represents the

AlgorithmParameters initial vector to be used if the Algorithm String HEX 0..1
attribute has a value of CBC.

Table 15-15 TransportKey Attributes

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

16. Application Data Request Message

The ApplicationDataRequest element contains the optional Batch ID which is the unique
identifier of the project and a list of CRNs for which the Application Provider needs to prepare the
application data and send it to the collator. The Batch ID is required when the intent of the
ApplicationDataRequest message is for customization of a batch of cards.

Figure 16-1 illustrates the ApplicationDataRequest element.

Figure 16-1 ApplicationDataRequest XML Diagram

Name Description Data Type Encoding No.

An ASCII field to identify the batch of

jobs between the SCMS and the
Personalization system. This
information is required by the collator
in order to identify XML messages
coming from different entities but
related to the same batch.

BatchID is required when data

Example:
SCMS_ID + Transaction Sequence
Number: 1.2.840.114283.0001

Table 16-1 ApplicationDataRequest Attributes

16.1.1 AID element

See section 15.4.1.

16.1.2 CRN element

See section 15.3.

Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 70/113

17. Card Customization Message

The CardCustomization element provides information to customize a unique card. This element
encapsulates the ModuleIdentifierCode which in turn includes the CardConfiguration and
the ApplicationData for all the applications to be customized on the card. Although it is more
logical to use this message for a post-issuance card customization, it could also be used to
customize a single card in pre-issuance card customization. It can be used for exchanges CI.CD.7
and CD.LO.2.

Figure 17-1 illustrates the CardCustomization element.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Figure 17-1 CardCustomization XML Diagram

Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 72/113

Name Description Data Type Encoding No.

An ASCII field to identify the batch of

jobs between the SCMS and the
Personalization system. This
information is required by the collator
in order to identify XML messages
coming from different entities, but
related to the same batch.

BatchID is required when the data

Example:
SCMS_ID + Transaction Sequence
Number: 1.2.840.114283.0001

Figure 17-2 CardCustomization Attributes

17.1 ModuleIdentifierCode element

The ModuleIdentifierCode element for ICC Data provides information related to the card
configuration for the Collator before the collation. During the collation process, all of the
ApplicationData elements sent from different application providers are appended to the
ModuleIdentifierCode until it contains all of the data for all of the applications (including the on
card Issuer Security Domain and Supplementary Security Domains) expected by the
CardConfiguration. The collator must append the ApplicationData elements in the same
order as defined in the AID order attribute found in the CardConfiguration element.

It is important to note that before the collation process, the ModuleIdentifierCode element
usually has only the CardConfiguration element to be used to collate all the ApplicationData
elements. However, if collation is done for some of the ApplicationData elements, then the
ModuleIdentifierCode element along with the appended ApplicationData elements will be
received by the collator to complete the collation for the remaining ApplicationData elements.

As the ModuleIdentifierCode is used in other XML elements and in order not to repeat this
section and sections that describe all the children elements of the ModuleIdentifierCode
element, its children elements are described in sub-sections of this section. Further messages
including the ModuleIdentifierCode element will reference this section.

Copyright  2003 GlobalPlatform Inc. All Rights Reserved.

Name Description Data Type Encoding No.

An identifier specifying that this is data

for chip card application(s).
Identifier String ASCII 1
Example:
ELECTRICAL

Figure 17-3 ModuleIdentifierCode Attributes

17.1.1 CardConfiguration element

The CardConfiguration element along with its parent ModuleIdentifierCode element and its
grandparent DataContainer element (if it’s used in the customization for a batch of cards) are
used by the collator to combine the ApplicationData elements from the various application
providers for each card into a set of multiple ApplicationData elements for the personalization
device.

The collator uses the CRN from this element and matches it with the CRNs placed as identifiers in
the ApplicationDataNotification message to collect all the ApplicationData elements as
specified in the AID elements.

This collation function may be performed at the Loader itself or alternatively at the Issuer, prior to
sending the personalization file to the Loader (bureau). If collation occurs at the Issuer, then the card
customization message is sent directly to the personalization system.

The CardConfiguration is also used by the personalization device to retrieve the appropriate
Card Profile and to perform the card customization in the order defined by the AID elements.

Name Description Data Type Encoding No.

Collator Status. Valid values are:

0 – Not Applicable
1 – request for collation
CollatorStatus String ASCII 1
2 – request for collation and collation
data
3 – collation data only
4 – collation complete

Table 17-1 CardConfiguration Attributes

17.1.2 AID element

See section 15.4.1.

17.1.3 CRN element

See section 15.3.

17.1.4 ValidCardProfileID element

The optional ValidCardProfileID element, if present, provides the UniqueID of the card
profiles which can be used for this card customization. If more than one ValidCardProfileID
elements are specified, the personalization system can chose any of them based on their availability.

Name Description Data Type Encoding No.

CardProfileUniqueID UniqueID of the card profile. String HEX N/A

Table 17-2 ApplicationProfileUniqueID Data Type

17.1.5 ApplicationData element

See section 15.4.

18. Batch Card Customization Message

The BatchCardCustomization element provides information to customize a batch of cards in
one or more jobs. The BatchCardCustomization elememt provides the batch identifier which is
a unique identifier for the included jobs. The BatchID attribute specified in the
BatchCardCustomization element is defined to allow the collation of data when two or more
entities are involved in this transaction. The entities include the Issuer, the Application Providers, the
Collator and the Loader. The BatchCardCustomization element contains at least one
EnvironmentContainer element. It can be used for exchanges CI.CD.7 and CD.LO.2.

Figure 18-1 illustrates the BatchCardCustomization element.

Figure 18-1 BatchCardCustomization XML Diagram

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.
October -03 GlobalPlatform Messaging Specification Page 77/113

Name Description Data Type Encoding No.

Identifies the batch of jobs between

the SCMS and the Personalization
system. This information is required
by the collator in order to identify XML
messages coming from different
entities, but related to the same batch.

BatchID is required when the data

preparation is requested for a batch of
BatchID cards. BatchID can be omitted when String ASCII 1
the data preparation is requested for a
single card as the CRN can be used to
identify personalization data
notification for a single card (i.e., in
case of post issuance personalization)

Example:
SCMS_ID + Transaction Sequence
Number: 1.2.840.114283.0001

Identifies the source of issuing

request. It could be different from the
sender in the GPHeader.
IssuingEntity String ASCII 1
Example:
SCMS_ID: 1.2.840.114283

Identifies the Loader responsible for

the card customization process. It
could be different from the receiver in
ProcessingEntity the GPHeader. String ASCII 1

Example:
BUREAU_ID: 1.2.840.115423

Can be used for proprietary

information.
User String ASCII 0..1
Example:
12345 (Order number)

Table 18-1 BatchCardCustomization Attributes

18.1 EnvironmentContainer element

The EnvironmentContainer element provides information on the required features which need
to be supported by the environment. For example, if the GP scripting language is used to perform the
card customization, then the environment needs to support the GP scripting language. A Loader
such as a personalization bureau may use the EnvironmentContainer element to spread the
workload across different devices. The EnvironmentContainer element contains at least one
JobContainer element.

Name Description Data Type Encoding No.

Description of the environment in

EnvironmentName which the data will be used. This can String ASCII 1
identify any environment.
Information field containing an
optional Environment version.
EnvironmentVersion String ASCII 1
Example:
1.2.1

Available for Load and Loader

environments. The field describes
whether a certain environment is ASCII
mandatory. Valid values are: *See
Preference String 1
description
Mandatory column
Compatible
Indifferent

Identifies whether the environment

supports the specified command ASCII
interpreter. Valid values are: *See
CommandInterpreterSupport String 1
description
Mandatory
column
Compatible
Indifferent

Describes the type of command

interpreter. Valid values are:
CommandInterpreterType String ASCII 1
GP Scripting
GCP

Contains command interpreter

version.
CommandInterpreterVersion String ASCII 1
Example:
1.2.1

Table 18-2 EnvironmentContainer Attributes

18.2 JobContainer
JobContainer element provides information on the priority, risk and cost for a batch of cards. The
issuer uses the JobContainer element to segment its jobs according to these criteria. For example,
within an EnvironmentContainer element there might be multiple JobContainer elements with
different deadlines based on the priority of the batch of cards to be processed. The JobContainer
element contains at least one DataContainerHeader element.

Name Description Data Type Encoding No.

JobID User defined. String ASCII 1

Provides the priority for each job
within the particular environment.
For example, the job and cost for SIM
cards may be "high" and the Job for ASCII
Loyalty card may be "low". Valid *See
JobPriorityLevel values are: String 1
description
column
N/A
High
Medium
Low

Used for costing or to determine the

number of sample validations to
perform on the personalized cards. ASCII
Valid values are: *See
RiskLevel String 1
description
N/A column
High
Medium
Low

Table 18-3 JobContainer Attributes

18.3 DataContainerHeader
The DataContainerHeader element specifies the card count and the type of plastic to use. The
DataContainerHeader element may also specify any special printing or artwork requirements.
For example, multiple DataContainerHeader elements may be defined; one for Platinum cards,
one for Gold cards and another one for Classic cards. The DataContainerHeader element
contains an optional CommonDataContainer element and at least one DataContainer
element.

Name Description Data Type Encoding No.

The date the personalization data

DataGenerationDate was generated in the format String ASCII 1
YYYYMMDDHHMMSS.

Name Description Data Type Encoding No.

A reference to the particular card

CardProductID String ASCII 1
product as assigned by the Issuer.
Information field containing an
optional Card product version.
CardProductVersion String ASCII 1
Example:
1.2.1

IssuerName The name of the Issuing entity. String ASCII 1

Number of cards to be processed in
CardRecordCount String ASCII 1
the hopper.
Identifier for the actual card stock to
PlasticStockID String ASCII 1
be used.
Date by which the cards must be
RequiredProcessingDate processed in the format String ASCII 1
YYYYMMDD.

Table 18-4 DataContainerHeader Attributes

18.4 CommonDataContainer
The optional CommonDataContainer element provides a set of card customization data
common for a subset of cards. CommonDataContainer is used to avoid unnecessary
replication of information. The Loader should parse the CommonDataContainer to find the
match with the relevant children elements of the DataContainer in order to regroup common and
specific data before starting the actual card customization required step. For example, the common
data could be the initial credit amount for an electronic purse valid for all the cards within the
DataContainerHeader.

The common data applies to all the cards within DataContainerHeader, the parent element of
the CommonDataContainer element.

If present, the CommonDataContainer element must have at least one

CommonModuleIdentifierCode element.

Name Description Data Type Encoding No.

None

Table 18-5 CommonDataContainer Attributes

18.5 CommonModuleIdentifierCode
The CommonModuleIdentifierCode element for ICC Data provides information related to the
card configuration and application data common to all the cards specified within the
DataContainerHeader. During the collation process, all the CommonApplicationData
elements sent from different application providers are appended to the
CommonModuleIdentifierCode until it contains all of the common data for all of the
applications.

It is important to note that both children of the CommonModuleIdentifierCode are optional.

This implies that it is possible to have only a CardCommonConfiguration element or only
CommonApplicationData element(s). The CommonModuleIdentifierCode element with
zero child element is not allowed.

Name Description Data Type Encoding No.

An identifier that specifies that this is

data for chip card application(s).
Identifier String ASCII 1
Example:
COMMON_ELECTRICAL

Table 18-6 CommonModuleIdentifierCode Attributes

18.6 CardCommonConfiguration element

The CardCommonConfiguration element provides the configuration information common to all
the cards specified within the DataContainerHeader. The CardCommonConfiguration
element must be used only in cases where all the information that it contains are valid for all the
cards specified within the DataContainerHeader.

Name Description Data Type Encoding No.

Collator Status. Valid values are:

0 – Not Applicable ASCII

1 – request for collation *See
CollatorStatus String 1
2 – request for collation and collation description
data column
3 – collation data only
4 – collation complete

Figure 18-2 CommonCardConfiguration Attributes

18.6.1 AID element

See section 15.4.1.

18.6.2 ValidCardProfileID element

See section 17.1.4.

18.7 ApplicationCommonData element

The ApplicationCommonData element contains part of application data that is common for all
the cards within the DataContainerHeader if the AID of the application is present in the list of
AIDs of the CardCommonConfiguration element. Otherwise, it applies only to those cards
within the DataContainerHeader whose CardConfiguration includes this AID. The
ApplicationCommonData element contains the ApplicationData element.

Name Description Data Type Encoding No.

None

Table 18-7 ApplicationCommonData Attributes

18.7.1 ApplicationData element

See section 15.4.

18.8 DataContainer
The DataContainer element provides the section of the data stream that contains the set of
personalization elements for every card to be personalized.

The DataContainer contains a set of ModuleIdentifierCode elements. These

ModuleIdentifierCode elements define the type of data for the particular card that is to be
personalized. For example, there may be different Module Identifiers for magnetic stripe data or for
embossing data. Any ModuleIdentifierCode elements not related to chip are out of scope for
this specification. All chip related data is contained in this DataContainer element, including data
necessary for collation.

Name Description Data Type Encoding No.

None

Table 18-8 DataContainer Attributes

18.8.1 ModuleIdentifierCode element

See section 17.1.

19. Application Audit Trail Message

The ApplicationAuditTrail element contains the information to be returned to the Application
Provider. This message can be used for the exchange CD.AP.1.

Figure 19-1 illustrates the ApplicationAuditTrail element.

Figure 19-1 ApplicationAuditTrail XML Diagram

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.
October -03 GlobalPlatform Messaging Specification Page 85/113

Name Description Data Type Encoding No.

Identifies the batch of jobs between

the SCMS and the Personalization
system. This information is required
by the collator in order to identify XML
messages coming from different
entities but related to the same batch.

BatchID is required when data

Example:
SCMS_ID + Transaction Sequence
Number: 1.2.840.114283.0001

Table 19-1 ApplicationAuditTrail Attributes

19.1 ApplicationCommonLog element

The optional ApplicationCommonLog element provides a set of application log data common
for all the CRN. This element is used to prevent the replication of the information per CRN.

ApplicationCommonLog encapsulates the ApplicationLog element. The

ApplicationCommonLog element applies to all the CRN within the ApplicationAuditTrail
message.

Name Description Data Type Encoding No.

None

Table 19-2 ApplicationCommonLog Attributes

19.2 ApplicationLog element

The ApplicationLog element contains the actual application log data for each application
customized or used to customize another application on the card. The ApplicationLog element
could be used to log card customization using the GlobalPlatform card customization technology (i.e.,
Profiles and Scripting) or any other alternative means. It is used as input for back-end application
data within an Application Provider running GlobalPlatform card customization technology or using
the common personalization approach defined in the EMV Card Personalization Specification. As the
ApplicationLog element is used in other XML elements and in order not to repeat this section and
sections that describe all the children elements of the ApplicationLog element, its children
elements are described in the sub-sections of this section. Other messages which specify the
ApplicationLog element will reference this section.

Name Description Data Type Encoding No.

None

Table 19-3 ApplicationLog Attributes

19.2.1 AID element

See section 15.4.1.

19.2.2 ApplicationProfileUniqueID element

See section 15.4.2.

19.2.3 ProcessingStepResult element

The ProcessingStepResult element provides information on the result of a processing step

undertaken during the card customization. The first three attributes Action, Requirement and
DataSet take the values from the ProcessingStep element and the StatusWords attribute reflects
the value provided by the personalization system.

Name Description Data Type Encoding No.

The action to be undertaken by the

personalization device.
Action String ASCII 1
Example:
PERSONALIZE

Name Description Data Type Encoding No.

Whether the step is required or

optional. For example, if the
processing step is to install an
application which is already installed,
when this attribute is specified as
required (01), it means that the
personalization device must delete the
Requirement already installed instance and install String ASCII 1
the new application instance.
Conversely, optional (00) means that
no delete and re-install is necessary.

Example:
00 (optional)
01 (required)

Optional DataSet name in the ICCData

DataSet String ASCII 0..1
to be used to perform this step.
Last Status Words returned by the
StatusWords String HEX 0..1
card for this step.

Table 19-4 ProcessingStepResult Attributes

19.2.4 Data element

See section 15.4.3.

19.2.5 DataSet element

See section 15.4.4.

19.2.6 Error element

See section 22.

19.2.7 LogData element

See section 15.4.6.

19.2.8 PersoDeviceIns element

The PersoDeviceIns element contains the original personalization device instructions within the
ApplicationData element. For more information, see section 15.4.7.

19.2.9 Script element

The Script element contains the original script information within the ApplicationData element.
For more information see section 15.4.9.
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 88/113

19.2.10 Signature element

The Signature element is an optional element. When present, it allows the verification of the integrity
of the ApplicationLogPerCRN. Signature is defined as per W3C. In order to ensure that the
application data corresponds to the associate CRN, the Signature must be computed over the
ApplicationLogPerCRN. For this, the Reference element of the Signature element must
reference the ApplicationLogPerCRN. After decollation, the Signature element could be carried
over to the Application Provider in order to keep the original value from the Loader. The entity that
verifies the signature must reconstruct ApplicationLogPerCRN XML element and compute the
signature for verification. If the Signature element is present in the ApplicationLog element within
the ApplicationCommonLog element, it should be computed over the ApplicationLog element.
For this purpose, the Reference element of the Signature must reference the ApplicationLog
element. W3C XML-Signature Syntax and Processing provides more information on how to compute a
signature and populate this XML element.

19.2.11 TransportKey element

See section 15.4.11.

19.3 ApplicationLogPerCRN element

The ApplicationLogPerCRN element provides the section of the audit information and log
specific to a card identified by the CRN element. In addition to the CRN element, it encapsulates the
ApplicationLog element.

Name Description Data Type Encoding No.

None

Table 19-5 ApplicationLogPerCRN Attributes

19.4 CRN element

See section 15.3.

19.5 ApplicationLog element

See section 19.2.

20. Batch Audit Trail Message

The BatchAuditTrail element contains the information to be returned by the Loader. This
message is to be used by the collator to decollate all the ApplicationLog elements and send them
over to the appropriate Application Providers. The rest of the message should be sent by the Collator
to the Issuer after the decollation.

Each attribute of the BatchAuditTrail element is a confirmation of the contents of the original
BatchCardCustomization element. The BatchAuditTrail element provides the batch
identifier, which is a unique identifier for the included jobs. It represents the original batch transaction
identifier. The BatchID attribute allows the receiver of the message to establish the relationship
between the original customization request and the log in the present message. The return step
code indicates the status of the transaction. If any exceptions occurred in the BatchAuditTrail,
then the Error element needs to be populated with the corresponding error code.

The BatchAuditTrail contains at least one EnvironmentContainerLog element. This

message can be used for exchanges LO.CD.1 and CD.CI.1.

Figure 20-1 illustrates the BatchAuditTrail element.

Figure 20-1 BatchAuditTrail XML Diagram

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.
October -03 GlobalPlatform Messaging Specification Page 91/113

Name Description Data Type Encoding No.

Identifies the batch of jobs between

the SCMS and the Personalization
system. This information is required
by the collator in order to identify XML
messages coming from different
entities, but related to the same batch.

BatchID is required when data

preparation is requested for a batch of
BatchID cards. BatchID can be omitted when String ASCII 1
data preparation is requested for a
single card as the CRN can be used to
identify personalization data
notification for a single card (i.e., in
case of post issuance personalization).

Example:
SCMS_ID + Transaction Sequence
Number: 1.2.840.114283.0001

Identifies the source of issuing

request. It could be different from the
sender in the GPHeader.
IssuingEntity String ASCII 1
Example:
SCMS_ID: 1.2.840.114283

Identifies the Loader responsible for

the card customization process. It can
be different from the receiver in the
ProcessingEntity GPHeader. String ASCII 1

Example:
BUREAU_ID: 1.2.840.115423

Can be used for proprietary

information.
User String ASCII 0..1
Example:
12345 (Order number)

Table 20-1 BatchAuditTrail Attributes

20.1 EnvironmentContainerLog element

The EnvironmentContainerLog element is used for audit purposes. This element must identify
the device used to personalize the batch of cards as well as the date on which the actual processing
occurred. If any exceptions occurred due to the original EnvironmentContainer element, the
audit data must identify the environment that was responsible for the personalization of the batch of
cards in question. In this case, the Error element needs to be populated with the corresponding
error code.

Name Description Data Type Encoding No.

Description of the environment in

EnvironmentName which the data will be used. This can String ASCII 1
identify any environment.
Information field containing an optional
Environment version.
EnviromentVersion String ASCII 1
Example:
1.2.1

Table 20-2 EnvironmentContainerLog Attributes

20.2 JobContainerLog element

The JobContainerLog element is used for audit and generally would be for confirmation. If any
exceptions occurred due to the original JobContainer element, then the Error element must be
populated with the corresponding error code.

Name Description Data Type Encoding No.

JobID Implementation dependent. String ASCII 1

Provides the priority for each job within
the particular environment. For
example, the job and cost for SIM
cards may be "high" and the Job for
Loyalty card may be "low". ASCII
*See
JobPriorityLevel String 1
Valid values are: description
column
N/A
High
Medium
Low

Name Description Data Type Encoding No.

Used for costing purposes or to

determine the number of sample
validations to perform on the ASCII
personalized cards. Valid values are: *See
RiskLevel String 1
description
N/A column
High
Medium
Low

Date in format YYYYMMDDHHMMSS ASCII

indicating when the job was *See
Date String 1
processed. description
column

Table 20-3 JobContainerLog Attributes

20.3 LogContainerHeader element

The LogContainerHeader element is used for audit purposes. It provides the confirmation of the
original DataContainerHeader element. If any exceptions occurred due to the original
DataContainerHeader element, then the Error element must be populated with the
corresponding error code.

Name Description Data Type Encoding No.

The date the personalization data was

DataGenerationDate generated in the format String ASCII 1
YYYYMMDDHHMMSS.
A reference to the particular card
CardProductID String ASCII 1
product as assigned by the Issuer.
Information field containing an optional
Card product version.
CardProductID String ASCII 1
Example:
1.2.1

IssuerName The name of the Issuing entity. String ASCII 1

Number of cards to be processed in
CardRecordCount String ASCII 1
the hopper.
Identifier for the actual card stock to be
PlasticCtockID String ASCII 1
used.
ASCII
Date in format YYYYMMDDHHMMSS
*See
ProcessingDate indicating when the cards were String 1
description
processed
column

Table 20-4 LogContainerHeader Attributes

Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 94/113

20.4 CommonLogContainer element

When present, the optional CommonLogContainer element provides a set of card customization
audit data common for a subset of cards. The CommonLogContainer element is used to
prevent unnecessary replication of information. The Issuer or the Application Provider should parse
the LogContainer element to find the match with the relevant children elements in order to regroup
common and specific data before starting the audit tracking management processing.

The common data applies to all the cards within the LogContainerHeader element, the parent
element of the CommonLogContainer element.

The CommonLogContainer element encapsulates the CommonLogIdentifierCode

element.

Name Description Data Type Encoding No.

None

Table 20-5 CommonLogContainer Attributes

20.5 LogContainer element

The LogContainer element is used for audit purposes. It may contain multiple
LogIdentifierCode (LIC) elements. LICs for magnetic stripe or embossing data are out of scope
of this specification. This specification only describes the RIC for the smart card audit data.

Name Description Data Type Encoding No.

None

Table 20-6 LogContainer Attributes

20.6 LogIdentifierCode element

The LogIdentifierCode element is used for audit purposes. The LogIdentifierCode element
for ICC Data provides information for the Collator before the decollation of data in order to send the
CardConfigurationLog element to the Issuer and splits ApplicationLog elements and sends
to the corresponding Application Providers.

This is important to note that before decollation the LogIdentifierCode element contains the
CardConfigurationLog element and multiple ApplicationLog elements. Once decollation is
done, the LogIdentifierCode element contains only the CardConfigurationLog element to
be sent to the Issuer.
Copyright  2003 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.
October -03 GlobalPlatform Messaging Specification Page 95/113

As the LogIdentifierCode element is used in other XML elements and in order not to replicate
this section and sections that describe all the children elements of the LogIdentifierCode
element, its children elements are described in the sub-sections of this section. Other messages
which utilize the LogIdentifierCode element will reference this section.

Name Description Data Type Encoding No.

An identifier that specifies that this is

data for chip card application(s).
Identifier String ASCII 1
Example:
LOG_ELECTRICAL

Table 20-7 LogIdentifierCod Attributes

20.6.1 AID element

See Section 15.4.1.

20.6.2 ApplicationLog element

See Section 19.2.

20.6.3 CardConfigurationLog element

The CardConfigurationLog element is used for audit purposes. It provides confirmation of the
original CardConfiguration element. If any exceptions occurred due to the original
CardConfiguration element, then the Error element needs to be populated with the
corresponding error code. If any exceptions occurred due to an issue related to the Collator, then the
Error element within CollatorReturnCode element needs to be populated with appropriate error
code. The DecollationStatus attribute provides information to the Decollator regarding the
decollation of the log.

Name Description Data Type Encoding No.

Collator Status. Valid values are:

DecollationStatus 0 – Not Applicable String ASCII 1

1 – Request for decollation
2 – Decollation complete

Table 20-8 CardConfigutationLog Attributes

20.6.4 CardLifeCycleState element

The CardLifeCycleState element is used for audit purposes. It indicates the card life cycle
reached at this stage. There may be multiple CardLifeCycleState elements as an exception may
occur during the card customization process that leaves the card in an unusable state.

Name Description Data Type Encoding No.

Implementation defined. It indicates

CardLifeCycleState String ASCII 1
the card life cycle reached at this stage

Table 20-9 CardLifeCycleState Attributes

20.6.5 CollatorReturnCode element

When present, the CollatorReturnCode element provides the result of the collation during the
original collation process. If any exceptions occurred due to an issue related to the Collator, then the
Error element within CollatorReturnCode element must be populated with appropriate error
code.

Name Description Data Type Encoding No.

The return code generated by the

Code String ASCII 1
Collator.

Table 20-10 CollatorReturnCode Attributes

20.6.6 CRN element

See Section 15.3.

20.6.7 Error element

See Section 19.2.6.

20.6.8 PhysicalCardIdentifier element

The PhysicalCardIdentifier element is used for audit purposes. It provides an identifier for the
physical card used. There may be multiple PhysicalCardIdentifier elements as an exception
may occur during the card customization process that leaves the card in an unusable state.

Name Description Data Type Encoding No.

User defined. It indicates the type of

identifier used to uniquely identify the
card.
IdentifierType String ASCII 1
Example:
CIN (Chip Image Number)

The value of the identifier specified by

IdentifierValue String HEX 1
IdentifierType.

Table 20-11 PhysicalCardIdentifier Attributes

20.6.9 MuteCardsNumber element

The MuteCardsNumber element is used for audit purposes. It specifies the number of the cards
that have been mute or became mute during the card customization process specific for this CRN.

Name Description Data Type Encoding No.

MuteCardsNumber Number of mute cards. Integer 1

Table 20-12 MuteCardsNumber Attributes

20.6.10 ValidCardProfileID element

The optional ValidCardProfileID element, if present, provides the UniqueID of the card profile that
is actually used for the card customization message. For more information, see 17.1.4.

20.7 CommonLogIdentifierCode element

The optional CommonLogIdentifierCode element is used for audit purposes. The
CommonLogIdentifierCode element provides information related to the card configuration log
and application log data common to all the card within the LogContainerHeader element. The
CommonLogIdentifierCode element provides information for the Collator prior to the
decollation of data. The decollator sends the CardCommonConfigurationLog element to the
Issuer and splits ApplicationCommonLog elements, sending the resultant pieces to the
corresponding Application Providers.

It is important to note that before decollation, if the CommonLogIdentifierCode element

contains a CardCommonConfigurationLog element and zero to multiple
ApplicationCommonLog elements, once the decollation is done, the
CommonLogIdentifierCode element contains only the CardCommonConfigurationLog
element to be sent to the Issuer. After the decollation, the ApplicationCommonLog elements
will be part of the ApplicationAuditTrail messages to be sent to the appropriate Application
Providers.

Furthermore, it is also important to note that both children of the CommonLogIdentifierCode

element are optional. This implies that is possible to have only one
CardCommonConfigurationLog element or one or more CommonApplicationLog
element(s). The CommonLogIdentifierCode with zero child is not allowed.

Name Description Data Type Encoding No.

An identifier that specifies that this is

data for chip card application(s).
Identifier String ASCII 1
Example:
COMMON_LOG_ELECTRICAL

Figure 20-2 CommonLogIdentifierCode Attributes

20.7.1 ApplicationCommonLog element

See section 19.1.

20.7.2 ApplicationLog element

See section 19.2.

20.7.3 CardCommonConfigurationLog element

The optional CardCommonConfigurationLog element is used for audit purposes. The

CardCommonConfigurationLog element provides the configuration information common for all
the cards specified within the LogContainerHeader. It also provides confirmation of the original
CardCommonConfiguration element. If any exceptions occurred due to the original
CardCommonConfiguration element, then the Error element needs to be populated with the
corresponding error code. If any exceptions occurred due to an issue related to the Collator, then the
Error element within CollatorReturnCode element should be populated with appropriate error
code. The DecollationStatus attribute provides information to the Decollator regarding the
decollation of data.

The CardCommonConfigurationLog element must be used only when all the information that
it contains is valid for all the cards within the LogContainerHeader.

Name Description Data Type Encoding No.

Collator Status. Valid values are:

DecollationStatus 0 – Not Applicable String ASCII 1

1 – Request for decollation
2 – Decollation complete

Table 20-13 CardCommonConfigurationLog Attributes

20.7.4 CollatorReturnCode element

See section 20.6.5.

20.7.5 Error element

See Section 22.

20.7.6 ValidCardProfileID element

The optional ValidCardProfileID element, if present, contains the UniqueID of the card profile
that is actually used for all the cards within the LogContainerHeader. For more information, see
Section 17.1.4.

21. Card Audit Trail Message

The CardAuditTrail element represents the information to be returned by the Loader or a post-
issuance download server and provides audit information related to one single card after card
customization.

The BatchAuditTrail provides the batch identifier which is a unique identifier for the transaction. It
represents the original batch transaction identifier. The optional batch ID is defined as an element to
allow the receiver of the message to make the relationship between the original customization
request and the log in the present message. This message can be used for exchanges LO.CD.1 and
CD.CI.1.

Figure 21-1 illustrates the CardAuditTrail element.

Figure 21-1 CardAuditTrail XML Diagram

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.
October -03 GlobalPlatform Messaging Specification Page 102/113

Name Description Data Type Encoding No.

Identifies the batch of jobs between

the SCMS and the personalization
system. This information is required
by the collator in order to identify XML
messages coming from different
entities but related to the same batch.

BatchID is required when data

preparation is requested for a batch of
BatchID cards. BatchID can be omitted when String ASCII 0..1
data preparation is requested for a
single card as the CRN can be used to
identify personalization data
notification for a single card (i.e., in
case of post issuance personalization).

Example:
SCMS_ID + Transaction Sequence
Number: 1.2.840.114283.0001
Table 21-1 CardAuditTrail Attributes

21.1 LogIdentifierCode element

See section 20.6.

22. Error Element

The Error element represents the information to be returned to original sender of the message in
order to acknowledge that an error occurred during the processing of the information. When the
Error element is appended to a specific element, it must specify the error code specific to that
element. When the Error element is appended to a message, it must indicate the error code
corresponding to message that it’s attached to.

Figure 22-1 illustrates the Error element.

Figure 22-1 Error XML Diagram

Name Description Data Type Encoding No.

Table 22-1 Error Attributes

Appendix A: GPMessages.1.0.0 XML Schema for

GlobalPlatform Messaging
The GlobalPlatform Messaging XML schema is provided in this section. The root element of this
scema is the element GPMessage.

Root = GPMessage

BASE24 R6.0 Post v10 2017-03-17 - BIC ISO Standards Manual
No ratings yet
BASE24 R6.0 Post v10 2017-03-17 - BIC ISO Standards Manual
308 pages
GP - Mapping of 2.1.1 Implementations To 2.2
0% (1)
GP - Mapping of 2.1.1 Implementations To 2.2
89 pages
EMV Response Message Formats
No ratings yet
EMV Response Message Formats
1 page
Iso8583 UDF Manual
No ratings yet
Iso8583 UDF Manual
2 pages
csfb400 Icsf Apg hcr77d1 PDF
No ratings yet
csfb400 Icsf Apg hcr77d1 PDF
1,720 pages
UnionPay CardE-Commerce Implementation Guide For Issuer-V9-20180104
No ratings yet
UnionPay CardE-Commerce Implementation Guide For Issuer-V9-20180104
48 pages
VMS Mag Stripe Encoding Specs
No ratings yet
VMS Mag Stripe Encoding Specs
1 page
API Fields SCMP
No ratings yet
API Fields SCMP
1,177 pages
Setup Guide: Card Printers in Cardwizard® Issuance Software
No ratings yet
Setup Guide: Card Printers in Cardwizard® Issuance Software
24 pages
Elite 790 User Guide
No ratings yet
Elite 790 User Guide
2 pages
Visa Merchant Data Standards Overview
100% (1)
Visa Merchant Data Standards Overview
120 pages
Eracom HSM
No ratings yet
Eracom HSM
43 pages
Standard 015 Eng
No ratings yet
Standard 015 Eng
174 pages
ATPC Install and Ops Guide 3.10 529056-002 PDF
No ratings yet
ATPC Install and Ops Guide 3.10 529056-002 PDF
251 pages
Dynamics AX Retail SDK Components Guide
No ratings yet
Dynamics AX Retail SDK Components Guide
10 pages
Merchant Onboarding Process Overview
No ratings yet
Merchant Onboarding Process Overview
20 pages
PCCharge 5.9.3 - Payment Server Manual
100% (1)
PCCharge 5.9.3 - Payment Server Manual
249 pages
UFR Series NFC Reader API
No ratings yet
UFR Series NFC Reader API
433 pages
1.1introduction of Technical Seminar:: Money Pad: The Future Wallet
No ratings yet
1.1introduction of Technical Seminar:: Money Pad: The Future Wallet
22 pages
A Guide To The ACI Worldwide BASE24-eps On z/OS: Front Cover
No ratings yet
A Guide To The ACI Worldwide BASE24-eps On z/OS: Front Cover
198 pages
Financial Inclusion Transaction Switch v1 3
100% (1)
Financial Inclusion Transaction Switch v1 3
25 pages
1 4
No ratings yet
1 4
20 pages
Encrypted Data File Analysis
No ratings yet
Encrypted Data File Analysis
2 pages
Merchant Agreement and Card Acceptance: Operating Guide
No ratings yet
Merchant Agreement and Card Acceptance: Operating Guide
28 pages
QVSDC IRWIN Testing Process
No ratings yet
QVSDC IRWIN Testing Process
8 pages
Manual JAVA POS Datalogic
100% (1)
Manual JAVA POS Datalogic
52 pages
TEUSER
No ratings yet
TEUSER
98 pages
EMV Security Review Emms, M. 2016
No ratings yet
EMV Security Review Emms, M. 2016
164 pages
How To Make Read From Ntfs File
No ratings yet
How To Make Read From Ntfs File
5 pages
Visa Pin Security Program Auditors Guide
No ratings yet
Visa Pin Security Program Auditors Guide
97 pages
Part VIII Display Card Specification
No ratings yet
Part VIII Display Card Specification
48 pages
200-338 - 0.2 Money Controls CcTalk User Manual
0% (2)
200-338 - 0.2 Money Controls CcTalk User Manual
226 pages
Full Guide To Install Apache Fineract On Ubuntu With A Bank Transfer Scenario
No ratings yet
Full Guide To Install Apache Fineract On Ubuntu With A Bank Transfer Scenario
40 pages
ATKEYBLWP
No ratings yet
ATKEYBLWP
9 pages
EMV Smart Card Vulnerabilities Exposed
No ratings yet
EMV Smart Card Vulnerabilities Exposed
9 pages
RuPay-Online Switching Interface Specification - V20.3
No ratings yet
RuPay-Online Switching Interface Specification - V20.3
304 pages
Atm Srs
No ratings yet
Atm Srs
12 pages
Small Merchant Guide To Safe Payments
No ratings yet
Small Merchant Guide To Safe Payments
28 pages
OS/2 Programming Guide: 4777 Magnetic Stripe Unit and 4778 PIN-Pad Magnetic Stripe Reader
No ratings yet
OS/2 Programming Guide: 4777 Magnetic Stripe Unit and 4778 PIN-Pad Magnetic Stripe Reader
132 pages
EPC Guidelines: Algorithms & Key Management
No ratings yet
EPC Guidelines: Algorithms & Key Management
57 pages
Apdu
0% (1)
Apdu
1 page
Integrated Circuit Card Specifications For Payment Systems: Cardholder, Attendant, and Acquirer Interface Requirements
No ratings yet
Integrated Circuit Card Specifications For Payment Systems: Cardholder, Attendant, and Acquirer Interface Requirements
104 pages
TC51 and TC56 Touch Computer
No ratings yet
TC51 and TC56 Touch Computer
4 pages
3-5-Emv L2
No ratings yet
3-5-Emv L2
6 pages
Ingenico POS Terminal Guide
No ratings yet
Ingenico POS Terminal Guide
7 pages
Gold SDK
No ratings yet
Gold SDK
13 pages
AN2646 Application Note: Smartcard Interface With The STM8S Microcontroller
No ratings yet
AN2646 Application Note: Smartcard Interface With The STM8S Microcontroller
43 pages
Verifone Unified Driver User Notes
No ratings yet
Verifone Unified Driver User Notes
31 pages
IP Manual
No ratings yet
IP Manual
1,182 pages
Verifone Ruby
100% (1)
Verifone Ruby
634 pages
International Standard: Iso/Iec 7816-5
No ratings yet
International Standard: Iso/Iec 7816-5
16 pages
EMV v4.3 Book 4 Other Interfaces 20120607062305603-1 PDF
No ratings yet
EMV v4.3 Book 4 Other Interfaces 20120607062305603-1 PDF
154 pages
Clear2Pay Payment Solutions Overview
No ratings yet
Clear2Pay Payment Solutions Overview
2 pages
VeriFone Unified Driver User Guide
No ratings yet
VeriFone Unified Driver User Guide
32 pages
Tandem HP
No ratings yet
Tandem HP
1 page
Manufacturing Equipment and Parts List
No ratings yet
Manufacturing Equipment and Parts List
52 pages
Recommendations For EMV Processing For Industry-Specific Tra
No ratings yet
Recommendations For EMV Processing For Industry-Specific Tra
18 pages
Global Platform-Card Specification - v2.2.1
No ratings yet
Global Platform-Card Specification - v2.2.1
303 pages
GPC CardSpecification v2.3.1 PublicRelease CC
No ratings yet
GPC CardSpecification v2.3.1 PublicRelease CC
334 pages
PCI HSM Security Requirements v1.0 Final
No ratings yet
PCI HSM Security Requirements v1.0 Final
26 pages
Security Accreditation Scheme For UICC Production - Standard 27 July 2016
No ratings yet
Security Accreditation Scheme For UICC Production - Standard 27 July 2016
18 pages
سفر روح PDF
No ratings yet
سفر روح PDF
357 pages
Datacard® CE870™ Instant Issuance System: User Reference Guide
No ratings yet
Datacard® CE870™ Instant Issuance System: User Reference Guide
13 pages
Acosj-P: Functional Specifications V1.06
No ratings yet
Acosj-P: Functional Specifications V1.06
21 pages
Getting Started With Java Card™ 3.0 Platform
No ratings yet
Getting Started With Java Card™ 3.0 Platform
41 pages
EMV v4.3 Book 1
100% (2)
EMV v4.3 Book 1
189 pages
GPC Specification v2.3
No ratings yet
GPC Specification v2.3
335 pages
Acosj-P: Functional Specifications V1.06
No ratings yet
Acosj-P: Functional Specifications V1.06
21 pages
Smartpersoware: Emv Chip Card Issuance System
No ratings yet
Smartpersoware: Emv Chip Card Issuance System
21 pages
Acosj-P: Java Card - PBOC 3.0
No ratings yet
Acosj-P: Java Card - PBOC 3.0
22 pages
PKI
No ratings yet
PKI
51 pages
Mobile Application Based On (U) SIM Java Card Applet Patrick Biget
No ratings yet
Mobile Application Based On (U) SIM Java Card Applet Patrick Biget
66 pages
Offcardverifierwp 150021 PDF
No ratings yet
Offcardverifierwp 150021 PDF
24 pages
Install & Configure OS: Grade 11 Module
100% (5)
Install & Configure OS: Grade 11 Module
45 pages
Data Sheet: Product: AFS670-EREEDAAATTEEEEEEPZZX08.0 Configurator: AFS670/675
No ratings yet
Data Sheet: Product: AFS670-EREEDAAATTEEEEEEPZZX08.0 Configurator: AFS670/675
3 pages
Bivariate Correlation Numerical Examples
No ratings yet
Bivariate Correlation Numerical Examples
4 pages
Management Memory - SQL - WinCC Tag Logging and Alarm Logging - Web
No ratings yet
Management Memory - SQL - WinCC Tag Logging and Alarm Logging - Web
2 pages
MODULE T2 - DCC50242 BIM Version 2.0 (Updated March 2022)
No ratings yet
MODULE T2 - DCC50242 BIM Version 2.0 (Updated March 2022)
150 pages
OSCP Certification Journey Guide
No ratings yet
OSCP Certification Journey Guide
6 pages
Multiobjective Optimization Answers
No ratings yet
Multiobjective Optimization Answers
3 pages
Log
No ratings yet
Log
44 pages
Exploring Wav2vec 2.0 Fine Tuning For Improved Speech Emotion Recognition
No ratings yet
Exploring Wav2vec 2.0 Fine Tuning For Improved Speech Emotion Recognition
5 pages
Exam: SC-900 Title: Microsoft Security, Compliance, and Identity Fundamentals Vendor: Microsoft Questions: 238
100% (2)
Exam: SC-900 Title: Microsoft Security, Compliance, and Identity Fundamentals Vendor: Microsoft Questions: 238
52 pages
15 HOTS Multiple Questions
No ratings yet
15 HOTS Multiple Questions
5 pages
AWS Cloud Governance Framework
No ratings yet
AWS Cloud Governance Framework
35 pages
MUSA Question Bank for DLCOA S.E Sem-III
No ratings yet
MUSA Question Bank for DLCOA S.E Sem-III
2 pages
2019 - IGD Indicator-Based Evolutionary Algorithm For Many-Objective Optimization Problems
No ratings yet
2019 - IGD Indicator-Based Evolutionary Algorithm For Many-Objective Optimization Problems
15 pages
Troubleshooting USB Driver Install
No ratings yet
Troubleshooting USB Driver Install
4 pages
PowerBASIC Compiler For Windows v10.0 PDF
No ratings yet
PowerBASIC Compiler For Windows v10.0 PDF
2,127 pages
Viva Questions Bharat Acharya 2018 8086 80386 Pentium
No ratings yet
Viva Questions Bharat Acharya 2018 8086 80386 Pentium
38 pages
Corporate Computer Security 4th Edition by Randall Boyle, Raymond Panko 0133545199 978-0133545197 PDF Download
100% (5)
Corporate Computer Security 4th Edition by Randall Boyle, Raymond Panko 0133545199 978-0133545197 PDF Download
75 pages
Project Report Quiz Master Application
No ratings yet
Project Report Quiz Master Application
4 pages
Graph Theory Exam Prep Guide
No ratings yet
Graph Theory Exam Prep Guide
3 pages
Questionnaire - Weblogic Fusion Middleware Administrator
No ratings yet
Questionnaire - Weblogic Fusion Middleware Administrator
3 pages
Indices and Standard From IG-1
No ratings yet
Indices and Standard From IG-1
3 pages
OPSMEN EARMOR Catalog 2024 EN V6 Web
No ratings yet
OPSMEN EARMOR Catalog 2024 EN V6 Web
32 pages
sns-en-IPSec VPN Authentication Certificates Technical Note
No ratings yet
sns-en-IPSec VPN Authentication Certificates Technical Note
18 pages
E. Queuing Theory
No ratings yet
E. Queuing Theory
18 pages
IGCSE Computer Science Paper 2 Mark Scheme
No ratings yet
IGCSE Computer Science Paper 2 Mark Scheme
16 pages
IDEA StatiCa Connection - Interface and Settings
No ratings yet
IDEA StatiCa Connection - Interface and Settings
12 pages
The Reactive API For Hibernate ORM. - Hibernate Reactive
No ratings yet
The Reactive API For Hibernate ORM. - Hibernate Reactive
2 pages
Pixma E510: Personal
No ratings yet
Pixma E510: Personal
10 pages
1 Sensor 3 Speed
No ratings yet
1 Sensor 3 Speed
45 pages