Book 3

EMV2000 Integrated Circuit Card Specification for Payment Systems

Book 3 Application Specification Version 4.0 December, 2000

© 2000 EMVCo, LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV 2000 Specifications (“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the user and EMVCo found at . These Materials and all of the content contained herein are provided "AS IS" "WHERE IS" and "WITH ALL FAULTS" and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these materials. EMVCO MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, WITH RESPECT TO THE MATERIALS AND INFORMATION CONTAINED HEREIN. EMVCO SPECIFICALLY DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY, AND FITNESS FOR A PARTICULAR PURPOSE. EMVCo makes no representation or warranty with respect to intellectual property rights of any third parties in or in relation to the Materials. EMVCo undertakes no responsibility of any kind to determine whether any particular physical implementation of any part of these Materials may violate, infringe, or otherwise use the patents, copyrights, trademarks, trade secrets, know-how, and/or other intellectual property rights of third parties, and thus any person who implements any part of these Materials should consult an intellectual property attorney before any such implementation. WITHOUT LIMITATION, EMVCO SPECIFICALLY DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES WITH RESPECT TO INTELLECTUAL PROPERTY SUBSISTING IN OR RELATING TO THESE MATERIALS OR ANY PART THEREOF, INCLUDING BUT NOT LIMITED TO ANY AND ALL IMPLIED WARRANTIES OF TITLE, NON-INFRINGEMENT OR SUITABILITY FOR ANY PURPOSE (WHETHER OR NOT EMVCO HAS BEEN ADVISED, HAS REASON TO KNOW, OR IS OTHERWISE IN FACT AWARE OF ANY INFORMATION). Without limitiation to the foregoing, the Materials provide for the use of public key encryption technology, which is the subject matter of patents in several countries. Any party seeking to implement these Materials is solely responsible for determining whether their activities require a license to any technology including, but not limited to, patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights.

December, 2000

Table of Contents

i

Table of Contents

1. 2. 3. 4.

Scope Normative References Definitions Abbreviations and Notations

vii viii x xii

Part I - Data Elements and Commands 1 Data Elements and Files 1.1 Data Elements Associated with Financial Transaction Interchange 1.2 Data Objects 1.2.1 Classes of Data Objects 1.3 Files 1.3.1 Application Elementary Files 1.3.2 File Referencing 1.4 Rules for Using a Data Object List (DOL) 2 Commands for Financial Transaction 2.1 Command APDU Format 2.2 Response APDU Format 2.3 Coding Conventions 2.3.1 Coding of the Class Byte 2.3.2 Coding of the Instruction Byte 2.3.3 Coding of Parameter Bytes 2.3.4 Coding of Data Field Bytes 2.3.5 Coding of the Status Bytes 2.3.6 Coding of RFU Data 2.4 Logical Channels 2.5 Commands 2.5.1 APPLICATION BLOCK Command-Response APDUs 2.5.2 APPLICATION UNBLOCK Command-Response APDUs 2.5.3 CARD BLOCK Command-Response APDUs 2.5.4 EXTERNAL AUTHENTICATE Command-Response APDUs 2.5.5 GENERATE APPLICATION CRYPTOGRAM Command-Response APDUs 2.5.6 GET CHALLENGE Command-Response APDUs 2.5.7 GET DATA Command-Response APDUs 2.5.8 GET PROCESSING OPTIONS Command-Response APDUs 2.5.9 INTERNAL AUTHENTICATE Command-Response APDUs 2.5.10 PIN CHANGE/UNBLOCK Command-Response APDUs 2.5.11 READ RECORD Command-Response APDUs 2.5.12 VERIFY Command-Response APDUs

14 17 18 19 21 22 23 25

Part II - Debit and Credit Application Specification 3 Files for Financial Transaction Interchange 3.1 Mandatory Data Objects 3.2 Data Retrievable by GET DATA Command

29 30 31

1 1 1 2 2 2 2 3 5 5 5 5 6 6 7 7 7 10 10 10 10 11 12 13

ii

Table of Contents

December, 2000

3.3 Data Retrievable by GET PROCESSING OPTIONS 3.4 Erroneous or Missing Data in the ICC 4 Transaction Flow 4.1 Exception Handling 4.2 Example Flowchart 4.3 Additional Functions 5 GENERATE AC Command Coding 5.1 Command Parameters 5.2 Command Data 5.2.1 Card Risk Management Data 5.2.2 Transaction Certificate Data 5.3 Command Use 5.3.1 GENERATE AC (First Issuance) 5.3.2 GENERATE AC (Second Issuance) 6 Functions Used in Transaction Processing 6.1 Initiate Application Processing 6.2 Read Application Data 6.3 Offline Data Authentication 6.4 Processing Restrictions 6.4.1 Application Version Number 6.4.2 Application Usage Control 6.4.3 Application Effective/Expiration Dates Checking 6.5 Cardholder Verification 6.5.1 Offline PIN Processing 6.5.2 Online PIN Processing 6.5.3 Signature Processing 6.5.4 Combination CVMs 6.6 Terminal Risk Management 6.6.1 Floor Limits 6.6.2 Random Transaction Selection 6.6.3 Velocity Checking 6.7 Terminal Action Analysis 6.8 Card Action Analysis 6.8.1 Terminal Messages for an AAC 6.8.2 Terminal Messages for a TC and ARQC 6.8.3 Advice Messages 6.9 Online Processing 6.10 Issuer-to-Card Script Processing 6.11 Completion

32 32 34 34 34 36 37 40 40 40 40 41 41 42 43 43 44 45 48 48 48 49 50 51 52 53 53 53 53 54 55 56 59 60 60 61 61 62 64

Annexes Annex A - Data Elements Table Annex B – Rules for BER-TLV Data Objects B.1 Coding of BER-TLV Data Objects B1.1 Coding of the Tag Field of BER-TLV Data Objects B1.2 Coding of the Length Field of BER-TLV Data Objects B1.3 Coding of the Value Field of Data Objects Annex C - Coding of Data Elements used in the Transaction Processing Annex C.1 - Application Interchange Profile

67 85 85 85 86 87 89 90

December, 2000

Table of Contents

Annex C.2 - Application Usage Control Annex C.3 - Cardholder Verification Rule Format Annex C.4 - Issuer Code Table Index Annex C.5 - Terminal Verification Results Annex C.6 - Transaction Status Information Annex D Transaction Processing for Chip Electronic Commerce D.1 System Architecture D.1.1 EMV Debit/Credit Applications D.1.2 Cardholder System D.1.3 Merchant Server D.1.4 Payment Gateway D.2 Transaction Processing D.2.1 Purchase Transaction Flow D.2.2 IC Card—Cardholder System Functions D.2.3 Cardholder System—Merchant Server Interface D.2.4 Merchant Server—Payment Gateway Interface Annex E - Issuer URL for Electronic Commerce Annex F - Electronic Commerce Cardholder System Flow Diagram Annex G - Electronic Commerce Cardholder System Implementations G.1 Overview G.2 Hosted Cardholder System G.3 Thick Client Cardholder System

iii 91 92 94 95 98 99 101 102 103 108 109 110 110 113 120 126 131 133 135 135 139 141

iv

Table of Contents

December, 2000

Table of Tables Table I - 1- Structure of SFI Table I - 2- Most Significant Nibble of the Class Byte Table I - 3- Coding of the Instruction Byte Table I - 4- Coding of Status Bytes SW1 SW2 Table I - 5- Allocation of Status Bytes Table I - 6- APPLICATION BLOCK Command Message Table I - 7- APPLICATION UNBLOCK Command Message Table I - 8 - CARD BLOCK Command Message Table I - 9- EXTERNAL AUTHENTICATE Command Message Table I - 10- GENERATE AC Cryptogram Types Table I - 11- GENERATE AC Command Message Table I - 12- GENERATE AC Reference Control Parameter Table I - 13- Format 1 GENERATE AC Response Message Data Field Table I - 14- Coding of Cryptogram Information Data Table I - 15- GET CHALLENGE Command Message Table I - 16- GET DATA Command Message Table I - 17- GET PROCESSING OPTIONS Command Message Table I - 18- Format 1 GET PROCESSING OPTIONS Response Message Data Field Table I - 19- INTERNAL AUTHENTICATE Command Message Table I - 20- PIN CHANGE/UNBLOCK Command Message Table I - 21- READ RECORD Command Message Table I - 22- READ RECORD Command Reference Control Parameter Table I - 23- READ RECORD Response Message Data Field Table I - 24- VERIFY Command Message Table I - 25- VERIFY Command Qualifier of Reference Data (P2) Table II - 1 - Data Objects Used by the Offline Data Authentication Algorithm Table II - 2 - Mandatory Data Objects Table II - 3 - Data Required for Offline Static Data Authentication Table II - 4 - Data Required for Offline Dynamic Data Authentication Table II - 5 - Data Objects Retrievable by GET DATA Command Table II - 6 - Data Retrievable by GET PROCESSING OPTIONS Table II - 7 - ICC Data Missing Indicator Setting Table A - 1 - Data Elements Dictionary Table A - 2 - Data Elements Tags Table B - 1 - Tag Field Structure (First Byte) BER-TLV Table B - 2 - Tag Field Structure (Subsequent Bytes) BER-TLV Table B - 3 - Primitive BER-TLV Data Object (Data Element) Table B - 4 - Constructed BER-TLV Data Object Table C - 1 - Application Interchange Profile Table C - 2 - Application Usage Control Table C - 3 - CVM Codes Table C - 4 - CVM Condition Codes Table C - 5 - Issuer Code Table Index Table C - 6 - Terminal Verification Results Table C - 7 - Transaction Status Information

3 6 7 8 9 11 12 13 14 15 15 16 16 17 18 19 20 20 21 23 24 24 24 25 25 30 30 30 31 31 32 33 80 83 85 86 87 87 90 91 92 93 94 97 98

December, 2000

Table of Contents

Table D - 1 - Issuer URL in FCI description Table D - 2 - Location of Issuer URL in FCI Template Table D - 3 - - Source of data requested in CDOL1 Table D - 4 - Converting CDOL1 Data for Terminal Action Analysis Table D - 5 - IC Card Data inputs to PInitReq Table D - 6 - Converting IC Card Data inputs to PInitReq Table D - 7 - IC Card Data inputs to Payment Instructions Table D - 8 - Converting IC Card Data to PI Inputs Table D - 9 - commonChip extension data and its sources Table E - 1 - Issuer URL data

v 102 102 118 119 122 122 124 125 126 131

vi

Table of Contents

December, 2000

Table of Figures Figure I-1 - Command APDU Structure Figure I-2 - Response APDU Structure Figure I-3 - Structural Scheme of Status Bytes Figure II- 1 - Transaction Flow Example Figure II- 2 - Use of GENERATE AC Options Figure II- 3 - Use of GENERATE AC with Referrals Figure II- 4 - Random Transaction Selection Example Figure II - 5- Issuer Script Format Figure II - 6- Issuer Script Command Format (Shown with Three Commands) Figure II- 7 - Chip Electronic Commerce System Figure II- 8 - Diagram of Chip Electronic Commerce transaction flow Figure E- 1 - Cardholder System Flow Diagram Figure G - 1 - Cardholder System components Figure G - 2 - Hosted Cardholder System example Figure G - 3 - Thick Client example

5 5 8 35 38 39 55 63 63 100 111 133 136 140 142

December, 2000

Scope

vii

1. Scope The Integrated Circuit Card Application Specification for Payment Systems (hereinafter referred to simply as ‘the Application Specification’) defines the terminal and integrated circuit card (ICC) procedures necessary to effect a payment system transaction in an international interchange environment. In particular it covers: •

Mapping of data elements to files

•

Transaction flow (the sequence of events and the commands issued to the card)

•

Exception processing

•

Coding of specific data objects (see Annexes C and D)

•

Definition of data elements and commands as they apply to the exchange of information between an ICC and a terminal. In particular,

¾Data elements for financial interchange and their mapping onto data objects. ¾Structure and referencing of files. ¾Structure and coding of messages between the ICC and the terminal to achieve application level functions. •

Chip Electronic Commerce Specification

The functions described are those necessary to ensure that payment system cards conforming to this specification can perform the set of common core functions in all terminals conforming to this specification. Application functions unique to individual payment systems and those functions not performed in interchange are not described, but are not precluded. This specification does not address clearing and settlement or any transactions where the ICC is not present. The Application Specification assumes familiarity with Book 1 (Application Independent IC Card to Terminal Interface Requirements), that describes functionality outside the application layer, including application selection. Both specifications are intended for use by payment system members, ICC and terminal manufacturers, and designers of applications using ICCs or interfacing to payment system applications that use ICCs.

viii

Normative References

December, 2000

2. Normative References The following standards contain provisions that are referenced in this specification. EMV2000 Version 4.0: December 1, 2000

Integrated Circuit Card Specification for Payment Systems Book 1 - Application Independent ICC to Terminal Interface Requirements

EMV2000 Version 4.0: December 1, 2000

Integrated Circuit Card Specification for Payment Systems Book 2 - Security and Key Management

EMV2000 Version 4.0: December 1, 2000

Integrated Circuit Card Specification for Payment Systems Book 4 - Cardholder, Attendant and Acquirer Interface Requirements

FIPS Pub 180-1:1995

Secure Hash Standard

IEC 512-2:1979

Specifications for electromechanical components for electromechanical equipment - Part 2: Contact resistance tests, insulation tests, and voltage stress tests

ISO 639:1988

Codes for the representation of names and languages

ISO 3166:1997

Codes for the representation of names of countries

ISO 4217:1995

Codes for the representation of currencies and funds

ISO/IEC 7811-1:1995

Identification cards – Recording technique - Part 1: Embossing

ISO/IEC 7811-3:1995

Identification cards – Recording technique - Part 3: Location of embossed characters on ID-1 cards

ISO/IEC 7813:1995

Identification cards – Financial transaction cards

ISO/IEC 7816-1:1998

Identification cards - Integrated circuit(s) cards with contacts - Part 1: Physical characteristics

ISO/IEC 7816-2:1998

Identification cards - Integrated circuit(s) cards with contacts - Part 2: Dimensions and location of contacts

ISO/IEC 7816-3:1997

Identification cards - Integrated circuit(s) cards with contacts - Part 3: Electronic signals and transmission protocols

ISO/IEC 7816-4:1995

Identification cards - Integrated circuit(s) cards with contacts - Part 4, Inter-industry commands for interchange

December, 2000

Normative References

ix

ISO/IEC 7816-5:1994

Identification cards - Integrated circuit(s) cards with contacts - Part 5: Numbering system and registration procedure for application identifiers

ISO/IEC 7816-6:1996

Identification cards - Integrated circuit(s) cards with contacts - Part 6: Inter-industry data elements (Draft International Standard)

ISO 8731-1:1987

Banking - Approved algorithms for message authentication Part 1: DEA

ISO 8372:1987

Information processing - Modes of operation for a 64-bit block cipher algorithm

ISO/IEC 8825:1990

Information technology - Open systems interconnection Specification of basic encoding rules for abstract syntax notation one (ASN.1)

ISO 8583:1987

Bank card originated messages - Interchange message specifications - Content for financial transactions

ISO 8583:1993

Financial transaction card originated messages - Interchange message specifications

ISO 8859:1987

Information processing - 8-bit single-byte coded graphic character sets

ISO/IEC 9796-2: 1997

Information technology - Security techniques - Digital signature scheme giving message recovery - Part 2: Mechanism using a hash function

ISO/IEC 9797:1994

Information technology - Security techniques - Data integrity mechanism using a cryptographic check function employing a block cipher algorithm

ISO/IEC 10116: 1997

Information technology - Modes of operation of an n-bit block cipher algorithm

ISO/IEC 10118-3: 1998

Information technology - Security techniques - Hash functions – Part 3: Dedicated hash functions

ISO/IEC 10373:1993

Identification cards - Test methods

x

Definitions

December, 2000

3. Definitions The following terms are used in this specification. Application - The application protocol between the card and the terminal and its related set of data. Byte - 8 bits. Card - A payment card as defined by a payment system. Command - A message sent by the terminal to the ICC that initiates an action and solicits a response from the ICC. Cryptogram - Result of a cryptographic operation. Cryptographic Algorithm - An algorithm that transforms data in order to hide or reveal its information content. Financial Transaction - The act between a cardholder and a merchant or acquirer that results in the exchange of goods or services against payment. Function - A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. Issuer Action Code - reflects the issuer’s selected action to be taken based upon the content of the TVR. Key - A sequence of symbols that controls the operation of a cryptographic transformation. Padding - Appending extra bits to either side of a data string. Path - Concatenation of file identifiers without delimitation. Payment System - For the purposes of this specification, Europay International S.A., MasterCard International Incorporated, or Visa International Service Association. Payment Systems Environment - The set of logical conditions established within the ICC when a payment system application conforming to this specification has been selected, or when a directory definition file (DDF) used for payment system application purposes has been selected. Response - A message returned by the ICC to the terminal after the processing of a command message received by the ICC.

December, 2000

Definitions

xi

Script - A command or a string of commands transmitted by the issuer to the terminal for the purpose of being sent serially to the ICC as commands. Template - Value field of a constructed data object, defined to give a logical grouping of data objects. Terminal - The device used in conjunction with the ICC at the point of transaction to perform a financial transaction. It incorporates the interface device and may also include other components and interfaces such as host communications. Terminal Action Code - Terminal Action Code(s) (Default, Denial, Online) reflects the acquirer-selected action to be taken upon the content of the TVR.

xii

Abbreviations and Notations

December, 2000

4. Abbreviations and Notations The following abbreviations and notations are used in this specification. AAC

Application Authentication Cryptogram

AAR

Application Authorisation Referral

AC

Application Cryptogram

ADF

Application Definition File

AEF

Application Elementary File

AFL

Application File Locator

AID

Application Identifier

an

Alphanumeric

ans

Alphanumeric Special

APDU

Application Protocol Data Unit

ARPC

Authorisation Response Cryptogram

ARQC

Authorisation Request Cryptogram

ASN

Abstract Syntax Notation

ATC

Application Transaction Counter

b

Binary

BER

Basic Encoding Rules

C

Celsius or Centigrade

C-APDU

Command APDU

CDOL

Card Risk Management Data Object List

CLA

Class Byte of the Command Message

cn

Compressed Numeric

C-TPDU

Command TPDU

CVM

Cardholder Verification Method

December, 2000


xiii

DDF

Directory Definition File

DDOL

Dynamic Data Authentication Data Object List

DES

Data Encryption Standard

DF

Dedicated File

DIR

Directory

EF

Elementary File

FCI

File Control Information

FIPS

Federal Information Processing Standard

hex.

Hexadecimal

HHMM

Hours, Minutes

HHMMSS

Hours, Minutes, Seconds

IC

Integrated Circuit

IAC

Issuer Action Code (Denial, Default, Online)

ICC

Integrated Circuit Card

IEC

International Electrotechnical Commission

IFD

Interface Device

INS

Instruction Byte of Command Message

I/O

Input/Output

ISO

International Organisation for Standardisation

KM

Master Key

KS

Session Key

Lc

Exact Length of Data Sent by the TAL in a Case 3 or 4 Command

lcm

Least Common Multiple

LDD

Length of the ICC Dynamic Data

Le

Maximum Length of Data Expected by the TAL in Response to a Case 2 or 4 Command

xiv


December, 2000

Licc

Exact Length of Data Available (or Remaining) in the ICC to be Returned in Response to the Case 2 or 4 Command Received by the ICC

LEN

Length

Lr

Length of Response Data Field

LRC

Longitudinal Redundancy Check

M

Mandatory

MAC

Message Authentication Code

max.

Maximum

MF

Master File

min.

Minimum

n

Numeric

NCA

Length of the Certification Authority Public Key Modulus

NI

Length of the Issuer Public Key Modulus

NIC

Length of the ICC Public Key Modulus

NPE

Length of the ICC PIN Encipherment Public Key Modulus

O

Optional

P1

Parameter 1

P2

Parameter 2

P3

Parameter 3

PAN

Primary Account Number

PCA

Certification Authority Public Key

PCB

Protocol Control Byte

PDOL

Processing Options Data Object List

PI

Issuer Public Key

PIC

ICC Public Key

December, 2000


PIN

Personal Identification Number

PSA

Payment System Application

PSE

Payment System Environment

R-APDU

Response APDU

RFU

Reserved for Future Use

RID

Registered Application Provider Identifier

RSA

Rivest, Shamir, Adleman Algorithm

R-TPDU

Response TPDU

SCA

Certification Authority Private Key

SI

Issuer Private Key

SIC

ICC Private Key

SFI

Short File Identifier

SHA

Secure Hash Algorithm

SW1

Status Word One

SW2

Status Word Two

TAC

Terminal Action Code(s) (Default, Denial, Online)

TAL

Terminal Application Layer

TC

Transaction Certificate

TDOL

Transaction Certificate Data Object List

TLV

Tag Length Value

TPDU

Transport Protocol Data Unit

TVR

Terminal Verification Results

var.

Variable

YYMMDD

Year, Month, Day

xv

xvi


December, 2000

The following notations apply: ‘0’ to ‘9’ and ‘A’ to ‘F’

16 hexadecimal digits

#

Number

[...]

Optional part

A := B

A is assigned the value of B

A=B

Value of A is equal to the value of B

A ≡ B mod n

Integers A and B are congruent modulo the integer n, that is, there exists an integer d such that (A - B) = dn

A mod n

The reduction of the integer A modulo the integer n, that is, the unique integer 0 ≤ r < n for which there exists an integer d such that A = dn + r

abs(n)

Absolute value of an integer n defined as n if n ≥ 0, and as −n if n<0

Y := ALG(K)[X]

Encipherment of a 64-bit data block X with a 64-bit block cipher as specified in Annex E1 using a secret key K

X = ALG-1(K)[Y]

Decipherment of a 64-bit data block Y with a 64-bit block cipher as specified in Annex E1 using a secret key K

Y := Sign (SK)[X]

The signing of a data block X with an asymmetric reversible algorithm as specified in Annex E2, using the private key SK

X = Recover(PK)[Y]

The recovery of the data block X with an asymmetric reversible algorithm as specified in Annex E2, using the public key PK

C := (A || B)

The concatenation of an n-bit number A and an m-bit number B, which is defined as C = 2m A + B.

H := Hash[MSG]

Hashing of a message MSG of arbitrary length using an 80-bit hash function

lcm(a, b)

Least common multiple of two integers a and b

|n|

Length of an integer n in bits

December, 2000 (X | n)


xvii

The Jacobi symbol of an integer X with respect to an integer n = pq consisting of the product of two primes p and q, and which is defined as follows. Define J := (X(p-1)/2 mod p)(X(q-1)/2 mod q) If J = 1 or J = (pq – p – q + 1), then (X  n) := 1. Otherwise, (X  n) := -1. Note that the Jacobi symbol can efficiently be computed without the prime factors of n (for example, see Informative Reference [5] in Annex G).

Xx

Any value

The following terminology is used: proprietary

Not defined in and/or outside the scope of this specification

shall

Denotes a mandatory requirement

should

Denotes a recommendation

xviii


THIS PAGE LEFT INTENTIONALLY BLANK

December, 2000

Part I Data Elements and Commands

December, 2000

Data Elements and Files

1

1 Data Elements and Files An application in the ICC includes a set of items of information. These items of information may be accessible to the terminal after a successful application selection (see Book 1, Part II of this specification). An item of information is called a data element. A data element is the smallest piece of information that may be identified by a name, a description of logical content, a format, and a coding.

1.1 Data Elements Associated with Financial Transaction Interchange The data element directory defined in Annex A, Table A-1 includes those data elements that may be used for financial transaction interchange. Data elements not specified in Annex A, Table A-1, are outside the scope of these specifications. Any additional data element transmitted in the response to the SELECT command (e.g. O/S Manufacturer proprietary data) is placed in the field “FCI Issuer Discretionary Data” (EMV tag ‘BF0C’).

1.2 Data Objects A data object consists of a tag, a length, and a value. A tag uniquely identifies a data object within the environment of an application. The length is the length of the value field of the data object. The value of a data object may consist either of a data element or of one or more data objects. When a data object encapsulates a data element, it is called a primitive data object. When a data object encapsulates one or more data objects, it is called a constructed data object. Specific tags are assigned to the constructed data objects with a specific meaning in the environment of an application according to this specification. The value field of such constructed data objects is a context-specific template. Rules for the coding of context-specific data objects and templates are given in Annex B. Upon receipt, the terminal shall parse all the data elements following the rules described in Annex B. The retrieved value fields of the data elements shall be stored in the terminal buffer for possible later use in the application. The terminals shall be capable of correctly interpreting TLV data objects with a length field coded '00’ as defined in ISO/IEC 7816. This situation can occur, when a data element is personalised on a card without an actual value field. A data element with length ‘00’ shall be treated as not present. The data element length indicated in Annex A, reflects the length of the data elements when actually present on the card.

2


December, 2000

Table A-1 and Table A-2 in Annex A describes the mapping of data elements onto data objects and the mapping of data objects into templates when applicable. Records are templates containing one or more primitive and/or constructed data objects. The mapping of data objects into records is left to the discretion of the issuer and the manner in which data elements are to be used is described in Part II of this book. Annex B defines the tags that are reserved by this specification for EMV, the payment systems, and issuers. All ICC applications conforming to this specification shall comply with this coding and allocation scheme in accordance with ISO/IEC 7816-6.

1.2.1 Classes of Data Objects Identification and coding of different classes of data objects are defined in Annex C. The tag definitions specified in that annex are according to ISO/IEC 8825 and ISO/IEC 7816 series and apply to applications conforming to this specification.

1.3 Files The data objects contained in data files accessible from the ICC are stored in records. The file structure and referencing method depend on the purpose of the file. Structures and referencing methods are described in the following sections. The layout of the data files accessible from the ICC is left to the discretion of the issuer except for the directory files described in the following section.

1.3.1 Application Elementary Files An AEF in the range 1-10, contains one or more primitive Basic Encoding Rules Tag Length Value (BER-TLV) data objects grouped into constructed BER-TLV data objects (records) according to Annex C. After selecting the application, an AEF in the range 1-10 is only referred to by its short file identifier (SFI) as described in section I-1.3.2. A data file referred to in this specification consists of a sequence of records addressed by record number. The data files referred to by SFIs in the range 1-10 contain only data not interpreted by the card, that is, data that is not used by the card in its internal processes. This file structure is defined as linear. It can be either linear fixed or linear variable according to ISO/IEC 7816-4. The choice is left to the issuer and does not affect the reading of the file according to this specification.

1.3.2 File Referencing A file may be referred to by a name or a SFI depending on its type.

December, 2000


3

1.3.2.1 Referencing by Name Any ADF or DDF in the card is referenced by its DF name. A DF name for an ADF corresponds to the AID or contains the AID as the beginning of the DF name. Each DF name shall be unique within a given card.

1.3.2.2 Referencing by SFI SFIs are used for the selection of AEFs. Any AEF within a given application is referenced by a SFI coded on 5 bits in the range 1 to 30. The coding of the SFI is described in every command that uses it. The structure of a SFI is according to Table I - 1: Value 1-10 11-20 21-30

Meaning Governed by this specification Payment system specific Issuer specific Table I - 1- Structure of SFI

A SFI shall be unique within an application. The coding of SFIs within the range 1 to 10 is used to address AEFs governed by this specification.

1.4 Rules for Using a Data Object List (DOL) In several instances, the terminal is asked to build a flexible list of data elements to be passed to the card under the card’s direction. To minimise processing within the ICC, such a list is not TLV encoded but is a single constructed field built by concatenating several data elements together. Since the elements of the constructed field are not TLV encoded, it is imperative that the ICC knows the format of this field when the data is received. This is achieved by including a Data Object List (DOL) in the ICC, specifying the format of the data to be included in the constructed field. DOLs currently used in this specification include the PDOL used with the GET PROCESSING OPTIONS command, CDOL1 and CDOL2 used with the GENERATE AC command, the TDOL used to generate a TC Hash Value, and the DDOL used with the INTERNAL AUTHENTICATE command. This section describes the rules for constructing a field using a DOL supplied by the card. A DOL is a concatenated list of entries, with each entry representing a single data element to be included in the constructed field. The format of each entry is a one- or two-byte tag identifying the desired data object, followed by a one-byte length, representing the number of bytes the field shall occupy in the command data. Only tags representing primitive data objects defined in Annex B shall be used in DOLs. The terminal shall complete the following steps to build the constructed field: 1.

Read the DOL from the ICC.

4

2.


December, 2000

Concatenate together all data elements listed in the DOL. The following rules apply to the creation of this concatenation: a)

If the tag of any data object identified in the DOL is unknown to the terminal or represents a constructed data object, the terminal shall provide a data element with the length specified and a value of all hexadecimal zeroes.

b)

If a data object is in the list and is meaningful to the terminal but represents optional static data that is absent from the ICC, the portion of the command field representing the data object shall be filled with hexadecimal zeroes.

c)

If the length specified in the DOL entry is less than the length of the actual data object, the leftmost bytes of the data element shall be truncated if the data object has numeric (n) format, or the rightmost bytes of the data shall be truncated for any other format. If the length specified is greater than the actual data, the actual data shall be padded: • With leading hexadecimal zeroes if the data has numeric format • With trailing hexadecimal FF’s if the data has compressed numeric (cn) format, • With trailing hexadecimal zeroes for any other format (an or ans).

d)

If a data object is in the list and is meaningful to the terminal but represents data that is not applicable to the current transaction, the portion of the command field representing the data object shall be filled with hexadecimal zeroes.

The completed list of data elements shall be concatenated in the sequence in which the corresponding data objects appear in the DOL.

December, 2000

Commands for Financial Transaction

5

2 Commands for Financial Transaction 2.1 Command APDU Format The command APDU consists of a mandatory header of four bytes followed by a conditional body of variable length, as shown in Figure I-1: CLA INS P1 P2 ← Mandatory Header →

Lc ← →

Data Le Conditional Body

Figure I-1 - Command APDU Structure The number of data bytes sent in the command APDU is denoted by Lc (length of command data field). The maximum number of data bytes expected in the response APDU is denoted by length of expected data (Le) . When Le is present and contains the value zero, the maximum number of available data bytes (up to 256) is expected . When required in a command message, Le shall always be set to ‘00’.

2.2 Response APDU Format The response APDU format consists of a conditional body of variable length followed by a mandatory trailer of two bytes, as shown in Figure I-2: Data ←

Body

→

SW1 SW2 ← Trailer →

Figure I-2 - Response APDU Structure The data field of a response APDU is an object structured as defined in Annex B. The detailed coding of the objects is provided with the commands described in subsequent sub-clauses.

2.3 Coding Conventions This section defines the coding of the header and the body of the messages (command and response).

6


December, 2000

2.3.1 Coding of the Class Byte The most significant nibble of the class byte codes the type of command as shown in Table I-2: Hex. ‘0’ ‘8’ Any other value

Meaning Inter-industry command Proprietary to this specification Outside the scope of this specification

Table I - 2- Most Significant Nibble of the Class Byte A command proprietary to this specification is introduced by the most significant nibble of the class byte set to ‘8’, in other words, the structure of the command and response messages is according to ISO/IEC 7816-4, the coding of the messages is defined within the context of the PSE. The least significant nibble of the class byte codes secure messaging and logical channel mechanisms, according to ISO/IEC 7816-4.

2.3.2 Coding of the Instruction Byte The INS byte of a command is structured according to Book 1, Part I of this specification. The coding of INS and its relationship to CLA as shown in Table I - 3 applies:

December, 2000


CLA ‘8x’ ‘8x’ ‘8x’ ‘0x’ ‘8x’ ‘0x’ ‘8x’ ‘8x’ ‘0x’ ‘8x’

INS ‘1E’ ‘18’ ‘16’ ‘82’ ‘AE’ ‘84’ ‘CA’ ‘A8’ ‘88’ ‘24’

‘0x’ ‘0x’ ‘0x’ ‘8x’ ‘8x’ ‘9x’ ‘Ex’

‘B2’ ‘A4’ ‘20’ ‘Dx’ ‘Ex’ ‘xx’ ‘xx’

7

Meaning APPLICATION BLOCK APPLICATION UNBLOCK CARD BLOCK EXTERNAL AUTHENTICATE GENERATE APPLICATION CRYPTOGRAM GET CHALLENGE GET DATA GET PROCESSING OPTIONS INTERNAL AUTHENTICATE PERSONAL IDENTIFICATION NUMBER (PIN) CHANGE/UNBLOCK READ RECORD SELECT VERIFY RFU for the payment systems RFU for the payment systems RFU for manufacturers for proprietary INS coding RFU for issuers for proprietary INS coding

Table I - 3- Coding of the Instruction Byte Note: Additional INS codes may be assigned in the future in the PSE context using the class ‘8x’. It is strongly recommended not to define proprietary commands in the class ‘8x’ when they are to be used in the PSE context, so that collision is avoided.

2.3.3 Coding of Parameter Bytes The parameter bytes P1 P2 may have any value. If not used, a parameter byte has the value ‘00’.

2.3.4 Coding of Data Field Bytes When present, an APDU command message data field consists of a string of data elements. When present, an APDU response data field consists of a data object or a string of data objects encapsulated in a template according to Annex B.

2.3.5 Coding of the Status Bytes The status bytes SW1 SW2 are returned by the transport layer to the application layer in any response message and denote the processing state of the command. The coding of the status words is structured according to Figure I-3:

8


December, 2000

SW1 SW2

Process Completed

Normal

‘61xx’ ‘9000’

Process Aborted

Warning

‘62xx’

Execution

‘63xx’‘64xx’

‘65xx’

Checking

‘67xx’ to ‘6Fxx’

Figure I-3 - Structural Scheme of Status Bytes

SW1

SW2

‘90’

‘00’

‘62’ ‘63’ ‘63’

‘83’ ‘00’ ‘Cx’

‘69’ ‘69’ ‘69’ ‘6A’ ‘6A’ ‘6A’ ‘6A’

‘83’ ‘84’ ‘85’ ‘81’ ‘82’ ‘83’ ‘88’

Meaning Normal processing Process completed (any other value for SW2 is RFU) Warning processing State of non-volatile memory unchanged; selected file invalidated State of non-volatile memory changed; authentication failed State of non-volatile memory changed; counter provided by ‘x’ (from 0-15) Checking errors Command not allowed; authentication method blocked Command not allowed; referenced data invalidated Command not allowed; conditions of use not satisfied Wrong parameter(s) P1 P2; function not supported Wrong parameter(s) P1 P2; file not found Wrong parameter(s) P1 P2; record not found Referenced data (data objects) not found

Table I - 4- Coding of Status Bytes SW1 SW2 The following values of SW1 SW2 are described in Book 1, Part I of this specification as they apply to the TPDU and are not returned to the APDU: • ‘61xx’: SW2 indicates the number of response bytes still available. • ‘6Cxx’: Wrong length Le, SW2 indicates the exact length. SW1 = ‘6x’ or ‘90’ denotes a normal, warning, or error condition coded according to ISO/IEC 7816-4. Other values of SW1 returned by the ICC are not supported by Book1, Part I. Table I-5 shows the coding of the SW1SW2 status bytes which this specification requires to be returned in response to specific conditions. The card may generate

December, 2000


9

SW1 ‘62’ ‘63’ ‘63’ ‘69’ ‘69’ ‘69’ ‘6A’ ‘6A’ ‘6A’ ‘6A’

SW2 ‘83’ ‘00’ ‘Cx’ ‘83’ ‘84’ ‘85’ ‘81’ ‘82’ ‘83’ ‘88’

VERIFY

SELECT

READ RECORD

PIN CHANGE/UNVBLOCK

INTERNAL AUTHENTICATE

GET PROCESSING OPTIONS

GET DATA

GET CHALLENGE

GENERATE APPLICATION CRYPTOGRM

EXTERNAL AUTHENTICATE

CARD BLOCK

APPLICATION UNBLOCK

APPLICATION BLOCK

status bytes not listed in this table for error and warning conditions not specified in the ICC Application Specification described in Part II of this book.

X X X X X X

X

X X

X X X

X

Table I - 5- Allocation of Status Bytes The following convention is used in the table: X=

Allowed response code, for which a dedicated action shall be taken or which has a special meaning for an EMV compliant application. The meaning of the action is explained in section 6.

10


December, 2000

2.3.6 Coding of RFU Data The coding of data (bits and bytes) indicated as RFU and marked as ‘x’ in the tables of the specifications shall be set to zero unless otherwise stated. To allow for migration and support of new functionality, the IC Card and the terminal shall not verify the data indicated as RFU.

2.4 Logical Channels A logical channel establishes and maintains the link between an application in the terminal and an application in the card. A card may support more than one logical channel but only the basic logical channel is supported by this specification. This limits to one the number of concurrent applications according to this specification.

2.5 Commands This section describes the following APDU command-response pairs: • • • • • • • • • • • •

APPLICATION BLOCK (post-issuance command) APPLICATION UNBLOCK (post-issuance command) CARD BLOCK (post-issuance command) EXTERNAL AUTHENTICATE GENERATE APPLICATION CRYPTOGRAM GET CHALLENGE GET DATA GET PROCESSING OPTIONS INTERNAL AUTHENTICATE PIN CHANGE/UNBLOCK (post-issuance command) READ RECORD VERIFY

The post-issuance commands shall only be sent using script processing (see Part II, Section 6.10) and secure messaging as specified in Book 2 of this specification.

2.5.1 APPLICATION BLOCK Command-Response APDUs 2.5.1.1 Definition and Scope The APPLICATION BLOCK command is a post-issuance command that invalidates the currently selected application. Following the successful completion of an APPLICATION BLOCK command:

December, 2000


11

•

An invalidated application shall return the status bytes ‘Selected file invalidated’ (SW1 SW2 = ‘6283’) in response to a SELECT command.

•

An invalidated application shall return only an AAC as AC in response to a GENERATE AC command.

2.5.1.2 Command Message The APPLICATION BLOCK command message is coded according to Table I - 6: Code CLA INS P1 P2 Lc Data

Le

Value ‘8C’ or ‘84’; coding according to the secure messaging specified in Book 2 of this specification ‘1E’ ‘00’; all other values are RFU ‘00’; all other values are RFU Number of data bytes Message Authentication Code (MAC) data component; coding according to the secure messaging specified in Book 2 of this specification Not present

Table I - 6- APPLICATION BLOCK Command Message

2.5.1.3 Data Field Sent in the Command Message The data field of the command message contains the MAC data component coded according to the secure messaging format specified in Book 2 of this specification.

2.5.1.4 Data Field Returned in the Response Message The data field of the response message is not present.

2.5.1.5 Processing State Returned in the Response Message ‘9000’ codes a successful execution of the command, independent whether the application was already invalidated or not.

2.5.2 APPLICATION UNBLOCK Command-Response APDUs 2.5.2.1 Definition and Scope The APPLICATION UNBLOCK command is a post-issuance command that rehabilitates the currently selected application. Following the successful completion of an APPLICATION UNBLOCK command, the restrictions imposed by the APPLICATION BLOCK command are removed.

12


December, 2000

2.5.2.2 Command Message The APPLICATION UNBLOCK command message is coded according to Table I - 7. Code CLA INS P1 P2 Lc Data Le

Value ‘8C’ or ‘84’; coding according to the secure messaging specified in Book 2 of this specification ‘18’ ‘00’; all other values are RFU ‘00’; all other values are RFU Number of data bytes MAC data component; coding according to the secure messaging specified in Book 2 of this specification Not present

Table I - 7- APPLICATION UNBLOCK Command Message



2.5.2.5 Processing State Returned in the Response Message ‘9000’ codes a successful execution of the command, independent whether the application was invalidated or not.

2.5.3 CARD BLOCK Command-Response APDUs 2.5.3.1 Definition and Scope The CARD BLOCK command is a post-issuance command that permanently disables all applications in the ICC. The CARD BLOCK command shall disable all applications in the ICC, including applications that may be selected implicitly. Following the successful completion of a CARD BLOCK command, all subsequent SELECT commands shall return the status bytes ‘Function not supported’ (SW1 SW2 = ‘6A81’) and perform no other action.

2.5.3.2 Command Message The CARD BLOCK command message is coded according to Table I - 8.

December, 2000

Code CLA INS P1 P2 Lc Data Le


13

Value ‘8C’ or ‘84’; coding according to the secure messaging specified in Book 2 of this specification ‘16’ ‘00’; all other values are RFU ‘00’; all other values are RFU Number of data bytes MAC data component; coding according to the secure messaging specified in Book 2 of this specification Not present Table I - 8 - CARD BLOCK Command Message



2.5.3.5 Processing State Returned in the Response Message ‘9000’ codes a successful execution of the command, independent of whether the card was already blocked or not.

2.5.4 EXTERNAL AUTHENTICATE Command-Response APDUs 2.5.4.1 Definition and Scope The EXTERNAL AUTHENTICATE command asks the application in the ICC to verify a cryptogram. The response from the ICC consists of returning the processing state of the command.

2.5.4.2 Command Message The EXTERNAL AUTHENTICATE command message is coded according to Table I - 9:

14

Commands for Financial Transaction Code CLA INS P1 P2 Lc Data Le

December, 2000

Value ‘00’ ‘82’ ‘00’ ‘00’ 8-16 Issuer Authentication Data Not present

Table I - 9 - EXTERNAL AUTHENTICATE Command Message The reference of the algorithm (P1) of the EXTERNAL AUTHENTICATE command is coded ‘00’, which means that no information is given. The reference of the algorithm is known either before issuing the command or is provided in the data field.

2.5.4.3 Data Field Sent in the Command Message The data field of the command message contains the value field of tag ‘91’ coded as follows: •

Mandatory first 8 bytes containing the cryptogram.

•

Optional additional 1-8 bytes are proprietary.


2.5.4.5 Processing State Returned in the Response Message ‘9000’ codes a successful execution of the command.

2.5.5 GENERATE APPLICATION CRYPTOGRAM CommandResponse APDUs 2.5.5.1 Definition and Scope The GENERATE AC command sends transaction-related data to the ICC, which computes and returns a cryptogram. This cryptogram shall either be an Application Cryptogram (AC) as specified in this specification or a proprietary cryptogram. In both cases, the cryptogram shall be of a type specified in Table I - 10 (for more details, see Part II).

December, 2000


Type Application Authentication Cryptogram (AAC) Application Authorisation Referral (AAR) Authorisation Request Cryptogram (ARQC) Transaction Certificate (TC)

15

Meaning Transaction declined Referral requested by the card Online authorisation requested Transaction approved

Table I - 10- GENERATE AC Cryptogram Types The cryptogram returned by the ICC may differ from that requested in the command message according to an internal process in the ICC (as described in Part II ).

2.5.5.2 Command Message The GENERATE AC command message is coded according to Table I - 11: Code CLA INS P1 P2 Lc Data Le

Value ‘80’ ‘AE’ Reference control parameter (see Table I - 12) ‘00’ Var. Transaction-related data ‘00’

Table I - 11- GENERATE AC Command Message The reference control parameter of the GENERATE AC command is coded as shown in Table I - 12:

16

Commands for Financial Transaction b8 0 0 1 1

b7 0 1 0 1

b6

b5

b4

b3

b2

b1

x

x

x

x

x

0

1

December, 2000

Meaning AAC TC ARQC RFU Combined DDA/AC generation not explicitly requested Combined DDA/AC generation requested RFU

Table I - 12- GENERATE AC Reference Control Parameter

2.5.5.3 Data Field Sent in the Command Message The content of the data field of the command message is coded according to the rules for the data object list as defined in section 1.4.

2.5.5.4 Data Field Returned in the Response Message The data field of the response message consists of a BER-TLV coded data object. The coding of the data object shall be according to one of the following two formats. • Format 1: The data object returned in the response message is a primitive data object with tag equal to ‘80’. The value field consists of the concatenation without delimiters (tag and length) of the value fields of the data objects specified in Table I - 13: Value Cryptogram Information Data Application Transaction Counter (ATC) Application Cryptogram (AC) Issuer Application Data

Presence M M M O

Table I - 13- Format 1 GENERATE AC Response Message Data Field • Format 2: The data object returned in the response message is a constructed data object with tag equal to ‘77’. The value field may contain several BER-TLV coded objects, but shall always include the Cryptogram Information Data, the Application Transaction Counter, and the cryptogram computed by the ICC (either an AC or a proprietary cryptogram). The utilisation and interpretation of proprietary data objects, which may be included in this response message, are outside the scope of these specifications.

December, 2000


17

Format 2 shall be used if the response is being returned in an envelope as specified for the Combined DDA/AC Generation feature described in Book 2 section 6.6. The required data elements for the response in an envelope are shown in Table 16 of that section.

For both formats, the Cryptogram Information Data returned by the GENERATE AC response message is coded according to Table I - 14: b8 0 0 1 1

b7 0 1 0 1

b6

x

b5

b4

b3

b2

B1

x 0 1 x 0 0 0 0 x

x 0 0 1 1 x

x 0 1 0 1 x

Meaning AAC TC ARQC AAR Payment System specific cryptogram No advice required Advice required Reason/advice/referral code No information given Service not allowed PIN Try Limit exceeded Issuer authentication failed Other values RFU

Table I - 14- Coding of Cryptogram Information Data


2.5.6 GET CHALLENGE Command-Response APDUs 2.5.6.1 Definition and Scope The GET CHALLENGE command is used to obtain an unpredictable number from the ICC for use in a security-related procedure. The challenge shall be valid only for the next issued command.

2.5.6.2 Command Message The GET CHALLENGE command message is coded according to Table I - 15:

18


December, 2000

Value ‘00’ ‘84’ ‘00’ ‘00’ Not present Not present ’00’

Table I - 15- GET CHALLENGE Command Message

2.5.6.3 Data Field Sent in the Command Message The data field of the command message is not present.

2.5.6.4 Data Field Returned in the Response Message The data field of the response message contains an 8-byte unpredictable number generated by the ICC.


2.5.7 GET DATA Command-Response APDUs 2.5.7.1 Definition and Scope The GET DATA command is used to retrieve a primitive data object not encapsulated in a record within the current application. The usage of the GET DATA command in this specification is limited to the retrieval of the primitive data objects ATC (tag ‘9F36’), Last Online ATC Register (tag ‘9F13’), or PIN Try Counter (tag ‘9F17’) defined in Annex A, Table A-1 that are interpreted by the application in the ICC.

2.5.7.2 Command Message The GET DATA command message is coded according to Table I - 16:

December, 2000


19

Value ‘80’ ‘CA’ ‘9F36’, ‘9F13’, or ‘9F17’ Not present Not present ‘00’

Table I - 16- GET DATA Command Message

2.5.7.3 Data Field Sent in the Command Message The data field of the command message is not present.

2.5.7.4 Data Field Returned in the Response Message The data field of the response message contains the primitive data object referred to in P1 P2 of the command message (in other words, including its tag and its length).


2.5.8 GET PROCESSING OPTIONS Command-Response APDUs 2.5.8.1 Definition and Scope The GET PROCESSING OPTIONS command initiates the transaction within the ICC. The response from the ICC consists of returning the Application Interchange Profile (AIP) and the Application File Locator (AFL).

2.5.8.2 Command Message The GET PROCESSING OPTIONS command message is coded according to Table I - 17:

20


December, 2000

Value ‘80’ ‘A8’ ‘00’; all other values are RFU ‘00’; all other values are RFU var. Processing Options Data Object List (PDOL) related data ‘00’

Table I - 17- GET PROCESSING OPTIONS Command Message

2.5.8.3 Data Field Sent in the Command Message The data field of the command message is a data object coded according to the Processing Options Data Object List (PDOL) provided by the ICC, as defined in section 1.4, and is introduced by the tag ‘83’. When the data object list is not provided by the ICC, the length field of the template is set to zero. Otherwise, the length field of the template is the total length of the value fields of the data objects transmitted to the ICC.

2.5.8.4 Data Field Returned in the Response Message The data field of the response message consists of a BER-TLV coded data object. The coding of the data object shall be according to one of the following two formats. • Format 1: The data object returned in the response message is a primitive data object with tag equal to ‘80’. The value field consists of the concatenation without delimiters (tag and length) of the value fields of the Application Interchange Profile (AIP) and the Application File Locator (AFL). The coding of the data object returned in the response message is shown in Table I - 18: ‘80’

Length

Application Interchange Profile

AFL

Table I - 18- Format 1 GET PROCESSING OPTIONS Response Message Data Field • Format 2: The data object returned in the response message is a constructed data object with tag equal to ‘77’. The value field may contain several BER-TLV coded objects, but shall always include the AIP and the AFL. The utilisation and interpretation of proprietary data objects, which may be included in this response message, are outside the scope of these specifications. The AIP specifies the application functions that are supported by the application in the ICC and is coded according to Part II of this book. The AFL consists of the list without delimiters of files and related records that shall be read according to the ICC Application Specification described in Part II of this book for the currently selected application.

December, 2000


21


2.5.9 INTERNAL AUTHENTICATE Command-Response APDUs 2.5.9.1 Definition and Scope The INTERNAL AUTHENTICATE command initiates the computation of the Signed Dynamic Application Data by the card using the challenge data sent from the IFD and data and a relevant private key stored in the card. The response from the ICC consists of returning the Signed Dynamic Application Data to the terminal.

2.5.9.2 Command Message The INTERNAL AUTHENTICATE command message is coded according to Table I 19: Code CLA INS P1 P2 Lc Data Le

Value ‘00’ ‘88’ ‘00’ ‘00’ Length of authentication-related data Authentication-related data ‘00’

Table I - 19- INTERNAL AUTHENTICATE Command Message The reference of the algorithm (P1) of the INTERNAL AUTHENTICATE command is coded ‘00’, which means that no information is given. The reference of the algorithm is known either before issuing the command or is provided in the data field.

2.5.9.3 Data Field Sent in the Command Message The data field of the command message contains the authentication-related data proprietary to an application. It is coded according to the Dynamic Data Authentication Data Object List (DDOL) as defined in Book 2 of this specification.

2.5.9.4 Data Field Returned in the Response Message The data field of the response message consists of a BER-TLV coded data object. The coding of the data object shall be according to one of the following two formats.

22


December, 2000

• Format 1: The data object returned in the response message is a primitive data object with tag equal to ‘80’. The value field consists of the value field of the Signed Dynamic Application Data as specified in Book 2 of this specification. • Format 2: The data object returned in the response message is a constructed data object with tag equal to ‘77’. The value field may contain several BER-TLV coded objects, but shall always include the Signed Dynamic Application Data as specified in Book 2 of this specification. The utilisation and interpretation of proprietary data objects which may be included in this response message are outside the scope of these specifications.


2.5.10

PIN CHANGE/UNBLOCK Command-Response APDUs

2.5.10.1

Definition and Scope

The PIN CHANGE/UNBLOCK command is a post-issuance command. Its purpose is to provide the issuer the capability either to unblock the PIN or to simultaneously change and unblock the reference PIN. Upon successful completion of the PIN CHANGE/UNBLOCK command, the card shall perform the following functions: •

The value of the PIN Try Counter shall be reset to the value of the PIN Try Limit.

•

If requested, the value of the reference PIN shall be set to the new PIN value.

The PIN data transmitted in the command, if present, shall be enciphered for confidentiality. Note: The reference PIN, which is stored within the card, is the one that is associated with the application and which the card uses to check the Transaction PIN Data transmitted within the VERIFY command.

2.5.10.2

Command Message

The PIN CHANGE/UNBLOCK command message is coded according to Table I - 20.

December, 2000 Code CLA

INS P1 P2 Lc Data

Le


23

Value ‘8C’ or ‘84’; coding according to the secure messaging specified in Book 2 of this specification ‘24’ ‘00’ ‘00’, ‘01’, or ‘02’ Number of data bytes Enciphered PIN data component, if present, and MAC data component; coding according to the secure messaging specified in Book 2 of this specification Not present

Table I - 20- PIN CHANGE/UNBLOCK Command Message P2:

If P2 is equal to ‘00’, the reference PIN is unblocked and the PIN Try Counter is reset to the PIN Try Limit. There is no PIN update, since the PIN CHANGE/UNBLOCK command does not contain a new PIN value. The usage of P2 equal to ‘01’ or ‘02’ is reserved for payment schemes. Any other value of P2 allowing PIN unblocking and/or PIN changing is out of the scope of this specification and shall be described for each payment system individually.

2.5.10.3

Data Field Sent in the Command Message

The data field of the command message contains the PIN data component, if present, followed by the MAC data component coded according to the secure messaging format specified in Book 2 of this specification.

2.5.10.4

Data Field Returned in the Response Message

The data field of the response message is not present.

2.5.10.5

Processing State Returned in the Response Message

‘9000’ codes a successful execution of the command.

2.5.11

READ RECORD Command-Response APDUs

2.5.11.1


The READ RECORD command reads a file record in a linear file. The response from the ICC consists of returning the record.

24


2.5.11.2

December, 2000

Command Message

The READ RECORD command message is coded according to Table I - 21: Code CLA INS P1 P2 Lc Data Le

Value ‘00’ ‘B2’ Record number Reference control parameter (see Table I - 22) Not present Not present ‘00’

Table I - 21- READ RECORD Command Message Table I - 22 defines the reference control parameter of the command message: b8 x

b7 x

b6 x

b5 x

b4 x

b3

b2

b1

1

0

0

Meaning SFI P1 is a record number

Table I - 22- READ RECORD Command Reference Control Parameter

2.5.11.3


The data field of the command message is not present.

2.5.11.4


The data field of the response message of any successful READ RECORD command contains the record read. For SFIs in the range 1-10, the record is a BER-TLV constructed data object as defined in Annex B and coded as shown in Table I - 23: ‘70’

Length

Record Template

Table I - 23- READ RECORD Response Message Data Field The response message to READ RECORD for SFIs outside the range 1-10 is outside the scope of this specification.

2.5.11.5


‘9000’ codes a successful execution of the command.

December, 2000


2.5.12

VERIFY Command-Response APDUs

2.5.12.1


25

The VERIFY command initiates in the ICC the comparison of the Transaction PIN Data sent in the data field of the command with the reference PIN data associated with the application. The manner in which the comparison is performed is proprietary to the application in the ICC. The VERIFY command applies when the Cardholder Verification Method (CVM) chosen from the CVM List is an offline PIN, as described in Part II of this book.

2.5.12.2

Command Message

The VERIFY command message is coded according to Table I - 24: Code CLA INS P1 P2 Lc Data Le

Value ‘00’ ‘20’ ‘00’ Qualifier of the reference data (see Table I-33) var. Transaction PIN Data Not present Table I - 24- VERIFY Command Message

Table I-33 defines the qualifier of the reference data (P2): b8 0 1 1 1

b7 0 0 0 0

B6 0 0 0 0

b5 0 0 0 0

b4 0 0 0 1

b3 0 0 x 0

B2 0 0 x 0

b1 0 0 x 0

1 1

0 0

0 0

0 0

1 1

0 1

x x

x x

1

0

0

1

x

x

x

x

Meaning As defined in ISO/IEC 7816-4 1 Plaintext PIN, format as defined below RFU for this specification Enciphered PIN, format as defined in Book 2 RFU for this specification RFU for the individual payment systems RFU for the issuer

Table I - 25- VERIFY Command qualifier of reference data (P2) The processing of the VERIFY command in the ICC will be defined in combination with the CVM rules as specified in Part II of this book.

1

The value of P2 = ‘00’ is not used by this specification.

26


December, 2000

The plaintext offline PIN block shall be formatted as follows: C

N

P

P

P

P

P/F P/F P/F P/F P/F P/F P/F P/F

F

F

where:

C N

Name Control field PIN length

P

PIN digit

P/F F

PIN/filler Filler

Value Binary 2 (hex. 0010) 4-bit binary number with permissible values of hex. 0100 to hex. 1100 4-bit field with permissible values of hex. 0000 to hex. 1001 Determined by PIN length 4-bit binary number with value of hex. 1111

P2 = ‘00’ indicates that no particular qualifier is used. The processing of the VERIFY command in the ICC should know how to find the PIN data unambiguously.

2.5.12.3


The data field of the command message contains the value field of tag ‘99’.

2.5.12.4


The data field of the response message is not present.

2.5.12.5


‘9000’ codes a successful execution of the command. When for the currently selected application the comparison between the Transaction PIN Data and the reference PIN data performed by the VERIFY command fails, the ICC shall return SW2 = ‘Cx’, where ‘x’ represents the number of retries still possible. When the card returns ‘C0’, no more retries are left, and the CVM shall be blocked. Any subsequent VERIFY command applied in the context of that application shall then fail with SW1 SW2 = ‘6983’.

Part II Debit and Credit Application Specification

December, 2000

Files for Financial Transaction Interchange

29

3 Files for Financial Transaction Interchange The description of the file structure and commands for accessing the files is found in Book 1, Part II (for the Application Selection) and Part I of this book for the application elementary files . The definition of each of the data objects is defined in Annex A. The payment system or issuer will map the appropriate data objects to files according to their needs, subject to the following restrictions: •

All files accessible using the READ RECORD command as defined in the Card Specification containing data objects defined in the Card Specification shall use short file identifiers (SFIs) in the range 1 to 10. These files:

−

Shall be linear files readable using the READ RECORD command as described in the Card Specification.

−

May contain multiple records. Each record is limited to 254 bytes, including tag and length.

−

Each record shall be coded as a constructed data object. The tag of the constructed data object shall be ‘70’ indicating a template proprietary to this specification, and the length field shall contain the total length of the encapsulated data objects.

−

Shall contain only data objects defined in this specification and coded in accordance with the Basic Encoding Rules - Tag Length Value (BER-TLV) described in Annex B.

−

May have access conditions to be satisfied for updates, but must be readable unconditionally.

•

Files with SFIs in the range 11 to 20 are reserved for proprietary data to be specified by the individual payment systems.

•

Files with SFIs in the range 21 to 30 are reserved for proprietary data to be specified by the issuer.

•

The Application File Locator (AFL) determines the files and records to be used for processing a transaction. The use of the AFL is described in section 6.2. The data objects listed in Table II - 1 are used by the offline data authentication algorithm and, when present, should be located in the first record referenced by the AFL.2

This allows the terminal to optionally perform the hashing necessary for data authentication in parallel with reading and parsing of data for other purposes.

2

30

Files for Financial Transaction Interchange Tag ‘8F’ ‘90’

December, 2000

Value Certification Authority Public Key Index Issuer Public Key Certificate

Table II - 1 - Data Objects Used by the Offline Data Authentication Algorithm Additional information may be found in complementary payment system documentation.

3.1 Mandatory Data Objects Table II - 2 lists the data objects that must be present in the ICC in files read using the READ RECORD command. All other data objects defined in this specification to be resident in such files in the card are optional. Tag ‘5F24’ ‘5A’ ‘8C’ ‘8D’

Value Application Expiration Date Application Primary Account Number (PAN) Card Risk Management Data Object List 1 Card Risk Management Data Object List 2

Presence M M M M

Table II - 2 - Mandatory Data Objects Table II - 3 lists the data objects that must be present if the ICC supports offline static data authentication. Table II - 4 lists the data objects that must be present if the ICC supports offline dynamic data authentication.3 Offline data authentication is required to support offline transactions but is optional in cards that support only online transactions. Tag ‘8F’ ‘90’ ‘93’ ‘92’ ‘9F32’

Value Certification Authority Public Key Index Issuer Public Key Certificate Signed Static Application Data Issuer Public Key Remainder Issuer Public Key Exponent

Table II - 3 - Data Required for Offline Static Data Authentication

The exception may be that the Issuer Public Key Remainder or the ICC Public Key Remainder could be absent. This is because if the public key modulus can be recovered in its entirety from the public key certificate there is no need for a remainder.

3

December, 2000


Tag ‘8F’ ‘90’ ‘92’ ‘9F32’ ‘9F46’ ‘9F47’ ‘9F48’ ‘9F49’

31

Value Certification Authority Public Key Index Issuer Public Key Certificate Issuer Public Key Remainder Issuer Public Key Exponent ICC Public Key Certificate ICC Public Key Exponent ICC Public Key Remainder Dynamic Data Authentication Data Object List (DDOL)4

Table II - 4 - Data Required for Offline Dynamic Data Authentication

3.2 Data Retrievable by GET DATA Command Data objects listed in Table II - 5 are not retrievable by the READ RECORD command but are retrieved by the terminal using the GET DATA command as described in the Card Specification. Of the objects listed here, only the Application Transaction Counter (ATC) is a mandatory data object, and it can be retrieved by either the GET DATA command or in the response to a GENERATE APPLICATION CRYPTOGRAM (AC) command. The terminal retrieves the ATC via the GET DATA command only if the ICC contains the Lower Consecutive Offline Limit and Upper Consecutive Offline Limit data objects. If the issuer does not wish terminal velocity checking to be performed and omits these data objects, the ICC does not need to support the GET DATA command. Tag ‘9F36’ ‘9F17’ ‘9F13’

Value Application Transaction Counter (ATC) PIN Try Counter Last Online ATC Register

Presence M O O

Table II - 5 - Data Objects Retrievable by GET DATA Command

In case the DDOL is not present in the card, the Default DDOL shall be used in stead. 4

32


December, 2000

3.3 Data Retrievable by GET PROCESSING OPTIONS Data objects listed in Table II - 6 are not retrievable by the READ RECORD command but are retrieved by the terminal using the GET PROCESSING OPTIONS command as described in Table II - 6 defines the data returned, not the format of the response; Part I Data Field Returned in the Response Message describes the format of the data when returned by the GET PROCESSING OPTIONS command.

Tag ‘82’ ‘94’

Value

Presence

Application Interchange Profile Application File Locator

M M

Table II - 6 - Data Retrievable by GET PROCESSING OPTIONS

3.4 Erroneous or Missing Data in the ICC Data objects in the card are classified in section 3.1 as either mandatory or optional. However, some optional data objects must be present to support optional functions selected by the issuer or must be present to avoid inconsistencies if other related data objects are present. When any mandatory data object is missing, the terminal terminates the transaction. When an optional data object is required because of the existence of other data objects or to support functions that must be performed due to the setting of bits in the Application Interchange Profile, the terminal sets to ‘1’ the ‘ICC data missing’ indicator in the TVR. Table II - 7 summarises the conditions under which this bit should be set to ‘1’. If none of the conditions in Table II- 7 apply, the bit shall be set to ‘0’. The setting of this bit is in addition to any other actions specified in other sections of this document.

Name

Tag

‘ICC Data Missing’ Shall Be Set If ...

Application Transaction Counter (ATC) Cardholder Verification Method (CVM) List Certification Authority Public Key Index Issuer Public Key Certificate Issuer Public Key Exponent

‘9F36’

ATC is not returned by GET DATA command and both Lower and Upper Consecutive Offline Limit data objects are present Not present and AIP indicates that cardholder verification is supported

‘8E’

‘8F’ ‘90’ ‘9F32’

Not present and AIP indicates offline static or dynamic data authentication is supported Not present and AIP indicates offline static or dynamic data authentication is supported Not present and AIP indicates offline static or dynamic data authentication is supported

December, 2000


Issuer Public Key Remainder

Last Online Application Transaction Counter (ATC) Register Signed Static Application Data ICC Public Key Certificate ICC Public Key Exponent ICC Public Key Remainder

‘92’

‘9F13’

‘93’ ‘9F46’ ‘9F47’ ‘9F48’

33

Not present and AIP indicates offline static or dynamic data authentication is supported and the ‘length of the Issuer Public Key’, as recovered from the Issuer Public Key Certificate, indicates that there was insufficient space for the entire Issuer’s Public Key in the certificate Last Online ATC Register is not returned by GET DATA command and both Lower and Upper Consecutive Offline Limits are present Not present and AIP indicates offline static data authentication is supported Not present and AIP indicates offline dynamic data authentication is supported Not present and AIP indicates offline dynamic data authentication is supported Not present and AIP indicates offline dynamic data authentication is supported and the ‘length of the ICC Public Key’, as recovered from the ICC Public Key Certificate, indicates that there was insufficient space for the entire ICC’s Public Key in the certificate

Table II - 7 - ICC Data Missing Indicator Setting It is up to the issuer to ensure that data in the card is of the correct format, and no format checking other than that specifically defined is mandated on the part of the terminal. However, if in the course of normal processing the terminal recognises that data is incorrectly formatted (for example, constructed data objects that do not parse correctly), the terminal shall terminate processing. This rule includes (but is not limited to): I. II. III. IV. V. VI. VII.

Constructed data objects that do not parse correctly. Dates that are out of range (for example, months that are not in the range 1 to 12). Other data that must be in a specific range of values but are not. CVM Lists with no Cardholder Verification Rules. Multiple occurrences of a data object that should only appear once. An AFL with no entries. An AFL entry with invalid syntax, that is, any one or more of the following: 1. An SFI of 0 or 31. 2. A starting record number of 0. 3. An ending record number less than the starting record number (byte 3 < byte 2). 4. Number of records participating in offline data authentication greater than the number of records (byte 4 > byte 3 - byte 2 + 1).

34

Transaction Flow

December, 2000

4 Transaction Flow The Application Interchange Profile specifies the application functions that are supported by the card. The terminal shall attempt to execute only those functions that the ICC supports. Book 1 describes all functionality outside the application layer, including the selection of the application. The functions described here begin after application selection has taken place. The remainder of this book deals with the terminal-to-ICC dialogue on the level of the application logical functions. Two transaction flows are described: • Section 6 Functions used in Transaction Processing. • Annex D Transaction Processing for Chip Electronic Commerce

4.1 Exception Handling Exceptions to normal processing are described in the Application Specification for specific status codes returned in the status bytes (SW1, SW2) or for missing data. Unless otherwise specified in the Application Specification, any SW1 SW2 returned by the transport layer to the application layer other than ‘9000’, ‘63Cx’, or ‘6283’ shall cause termination of the transaction.5 This requirement applies to the Application Specification but does not apply to the application selection process..

4.2 Example Flowchart The flowchart in Figure II-8 gives an example of a transaction flow that may be used by a terminal for a normal purchase transaction. This flowchart is only an example, and the order of processing may differ from that given here. All restrictions on the order of processing are provided in section 6 and Annex D.

Other actions may be taken by prior agreement but are outside the scope of this specification.

5

December, 2000

Transaction Flow

35

Initiate Application

Read Application Data

Data Authentication

In this example, Terminal Risk Management is performed in parallel with other functions.

Terminal Risk Management

Processing Restrictions

Cardholder Verification

Terminal Action Analysis

Card Action Analysis

Online / Offline Decision

Online

Online Processing & Issuer Authentication

Offline

Completion

Script Processing

Figure II- 1 - Transaction Flow Example

36

Transaction Flow

December, 2000

4.3 Additional Functions Provision has been made in this specification for additional functions beyond those described here. Such additional functions may be: •

Future additions to this specification

•

Proprietary functions implemented by local or national agreement or by the individual payment systems

The Application Interchange Profile indicates the functions supported in the ICC according to this specification. Most of the bits in this data object are reserved for future use (RFU). When a new function is added, a bit in the Application Interchange Profile will be allocated to indicate support for the new function, and this specification will be updated to specify the new function and where it fits into the transaction flow. Proprietary functions may be added to the terminal and the ICC application as long as they do not interfere with processing of terminals and ICCs not implementing the function. For example, offline dynamic data authentication based on symmetric keys may be added at local option. Such proprietary functions, while not described in this specification, are not precluded, as long as the functions specified herein continue to be supported for ICCs not implementing the proprietary functions.

December, 2000

Generate AC Command Coding

37

5 GENERATE AC Command Coding The GENERATE AC command format and response codes are described fully in section 2.5.5. This section describes how the various options and data elements are used in transaction processing. Figure II- 2 and Figure II- 3 depict the interaction between the terminal decisions, ICC decisions, issuer approval, the GENERATE AC command, and the possible ICC responses. Figure II- 2 describes the overall flow; Figure II- 3 provides the additional logic for referral transactions. The complete transaction flow is not shown in these charts, only the GENERATE AC commands, responses, and associated decisions.

38


December, 2000

Earlier Processing

Reject Offline

Terminal Decision

Approve Offline

Online

Terminal Requests AAC

Terminal Requests ARQC

Card responds with AAC

Reject

No

TAC/IACDefault

Approve

Reject

Card decision

Terminal Requests TC

Refer

Online

Card decision

Online

Refer

Card responds with ARQC

Card responds with AAR

Completed Online?

Referral Processing (see Figure 6)

Offline Approve

Reject

Card responds with TC

Card responds with AAC

Authorization Response Code

Reject

Approve

Terminal requests AAC

Terminal requests TC

Card returns AAC

Card returns TC or AAC

Figure II- 2 - Use of GENERATE AC Options

December, 2000


39

Card initiates referral processing

External procedures may take effect. See payment systems documentation.

Terminal selects option

Offline

Terminal supplies Auth. Response Code

Online

Using AAR as ARQC, go online

Auth Resp Code

Reject

Terminal Requests AAC

Reject

Card returns AAC

Approve Online Auth Response Code

Approve

Terminal Requests TC

Reject Request AAC

Card Option Approve

Card returns AAC

Card returns TC

Figure II- 3 - Use of GENERATE AC with Referrals

40


December, 2000

5.1 Command Parameters The GENERATE AC command parameters provide three different options to the terminal: •

Request for the generation of a TC

•

Request for the generation of an ARQC

•

Request for the generation of an AAC

5.2 Command Data The data field of the GENERATE AC command is not TLV encoded, so it is imperative that the ICC know the format of this data when the command is received. This is achieved by allowing the ICC to specify the format of the data to be included in the command. This section describes how the ICC makes that specification.

5.2.1 Card Risk Management Data The Card Risk Management Data Object List (CDOL) is a data object in the ICC that provides to the terminal a list of data objects that must be passed from the terminal to the ICC in the GENERATE AC command. There shall be two CDOLs in the ICC, referred to as CDOL1 (tag ‘8C’) and CDOL2 (tag ‘8D’). CDOL1 is used with the first GENERATE AC command, and CDOL2 is used with the second GENERATE AC command (if used). The terminal uses the appropriate CDOL and the rules specified in section 1.4 (see ‘Rules for Processing Data Object Lists (DOLs)’) to build the appropriate data field for the command. It is the responsibility of the terminal to ensure that current data is used in building the GENERATE AC command. To this end, the command data should be built immediately prior to issuing the GENERATE AC command.

5.2.2 Transaction Certificate Data A CDOL may request a TC Hash Value to be included in the command data of a GENERATE AC command. The TDOL is a data object that provides to the terminal a list of data objects to be used in generating the TC Hash Value. The ICC may contain the TDOL, but there may be a default TDOL in the terminal, specified by the payment system, for use in case the TDOL is not present in the ICC. To create the hash value, the terminal shall use the TDOL (if present) or the default TDOL to create the appropriate value for input to the hash algorithm, applying the rules specified in section 1.4 (see ‘Rules for Processing Data Object Lists (DOLs)’). If the default TDOL is used, the terminal shall set to ‘1’ the ‘Default TDOL used’ bit in the TVR. If a default TDOL is required but is not present in the terminal, a default TDOL with no data objects in the list shall be assumed.

December, 2000


41

If the terminal issues a second GENERATE AC command during the processing of a transaction, the terminal shall ensure that the data provided in the TC Hash Value is current at the time the command is issued.

5.3 Command Use Either one or two GENERATE AC commands are issued during the processing of a transaction according to this specification. The ICC shall respond to the first GENERATE AC command with any of the following: • TC • ARQC • AAR • AAC The ICC shall respond to a second GENERATE AC command with either a TC or an AAC. The possible responses listed above are in hierarchical order, with a TC being the highest and an AAC being the lowest. The terminal may request a TC, an ARQC, or an AAC. If the ICC responds with a cryptogram at a higher level, this indicates a logic error in the ICC. If this occurs after the first GENERATE AC command in a transaction, the transaction shall be terminated. If it occurs after the second GENERATE AC command, all processing for the transaction has been completed, and the cryptogram returned shall be treated as an AAC.

5.3.1 GENERATE AC (First Issuance) The terminal completes its online/offline decision process with a GENERATE AC command (see section 2.5.5). The form of the command depends upon the decision made by the terminal: •

If the terminal decides the transaction might be completed offline, it requests a TC from the ICC. The ICC shall reply with a TC, an ARQC, an AAR, or an AAC, depending upon its own analysis of the transaction.

•

If the terminal decides the transaction should go online, it requests an ARQC from the ICC. The ICC shall reply with an ARQC, an AAR, or an AAC.

•

If the terminal decides to reject the transaction, it requests an AAC from the ICC. The ICC shall reply with an AAC.

If the ICC responds with a TC or an AAC, the terminal completes the transaction offline. If the ICC responds with an AAR, the terminal either provides an Authorisation Response Code and proceeds to the completion function or uses the AAR to go online. See Figure II – 3 for referral processing logic.

42


December, 2000

If the ICC responds with an ARQC, the terminal attempts to go online, sending an authorisation request message to the issuer. Included in the authorisation request message is the ARQC for online card authentication.

5.3.2 GENERATE AC (Second Issuance) Whether the terminal receives an authorisation response message as a result of online processing or an approval or rejection by using the Issuer Action Code Default, it completes the transaction by requesting either a TC (in the case an approval was obtained) or an AAC (in case the issuer’s instruction is to reject the transaction) from the ICC. If a TC was requested, the ICC shall reply with either a TC or an AAC. If an AAC was requested, the card shall reply with an AAC. The ICC shall permit at most two GENERATE AC commands in a transaction. If the terminal issues more than two, the third and all succeeding GENERATE AC commands shall end with SW1 SW2 = ‘6985’, and no cryptogram shall be returned.

December, 2000

Functions Used in Transaction Processing

43

6 Functions Used in Transaction Processing 6.1 Initiate Application Processing Purpose: Inform the ICC that the processing of a new transaction is beginning and provide to the ICC the terminal information about the transaction. Obtain from the ICC the Application Interchange Profile and a list of files that contain the ICC data to be used in processing the transaction, and determine whether the transaction is allowed. Conditions of Execution: The terminal shall always execute this function. Sequence of Execution: This is the first function performed after application selection. Description: The terminal sets all bits in the Transaction Status Information (TSI) and the Terminal Verification Results (TVR) to ‘0’.6 The Processing Options Data Object List (PDOL) is a list of tags and lengths of terminal-resident data elements needed by the ICC in processing the GET PROCESSING OPTIONS command. Only data elements identified in the Card Specification as having the terminal as the source of the data may be referenced in the PDOL. If the PDOL does not exist, the GET PROCESSING OPTIONS command uses a command data field of ‘8300’, indicating that the length of the value field in the command data is 0. If the PDOL exists, the terminal extracts the PDOL from the FCI of the ADF and uses it to create a concatenated list of data elements without tags or lengths. The rules specified in section 1.4 (see ‘Rules for Processing a Data Object List (DOL)’) apply to processing of the PDOL. If an amount field (either Amount, Authorised or Amount, Other) is referenced in the PDOL and the terminal is unable to provide the amount at this point in transaction processing, the amount field in the data element list shall be filled with hexadecimal zeroes. The terminal issues the GET PROCESSING OPTIONS command using either the command data field of ‘8300’ (if there was no PDOL in the ICC) or a data object constructed with a tag of ‘83’ and the appropriate length according to

There may be some exceptions in the timing for this. For example, these bits could be set to ‘0’ at the completion of the previous transaction or prior to application selection of this transaction. The intent here is that the processing steps as described in the Application Specification presume the bits have been initialised to ‘0’.

6

44


December, 2000

BER-TLV encoding rules and a value field that is the concatenated list of data elements resulting from processing the PDOL. The card returns either: •

The Application Interchange Profile, the Application File Locator (identifying the files and records containing the data to be used for the transaction), and status SW1 SW2 = ‘9000’, or

•

Status SW1 SW2 = ‘6985’ (‘Conditions of use not satisfied’), indicating that the transaction cannot be performed with this application.

The format of the response message is given in section 2.5.8. If the status words ‘6985’ are returned, the terminal shall eliminate the current application from consideration and return to the application selection function to select another application.

6.2 Read Application Data Purpose: Data contained in files in the ICC are required by the terminal to perform the various functions used in transaction processing as described in this section. The terminal must read this data from the ICC. Conditions of Execution: The terminal shall always execute this function. Sequence of Execution: The read application data function is performed immediately following the initiate application function. Description: The terminal shall read the files and records indicated in the Application File Locator using the READ RECORD command identifying the file by its SFI. If an error prevents the terminal from reading data from the ICC, the transaction shall be terminated (see section 4.1). The AFL is a list identifying the files and records to be used in the processing of a transaction. The terminal is to read only the records named in the AFL. Each element of the list corresponds to a file to be read and is structured as follows: • The first byte codes the SFI in the five most significant bits. The three least significant bits of the first byte shall be set to zero. • The second byte codes the first (or only) record number to be read for that SFI. The second byte shall never be set to zero. • The third byte codes the last record number to be read for that SFI. Its value is either greater than or equal to the second byte. When the third byte is greater than the second byte, all the records ranging from the record number in the second byte to and including the record number in the third byte shall

December, 2000


45

be read for that SFI. When the third byte is equal to the second byte, only the record number coded in the second byte shall be read for that SFI. • The fourth byte codes the number of records involved in offline data authentication starting with the record number coded in the second byte. The fourth byte may range from zero to the value of the third byte less the value of the second byte plus 1. The terminal shall process each entry in the AFL from left to right. A READ RECORD command as described in section 2.5.11 shall be issued for each record between the starting record number and the ending record number, inclusively. Any SW1 SW2 other than ‘9000’ passed to the application layer as a result of reading any record shall cause the transaction to be terminated. Records specified in the AFL to be included in offline data authentication shall be processed as described in section 6.3. The terminal shall store all recognised data objects read, whether mandatory or optional, for later use in the transaction processing. Data objects that are not recognised by the terminal (that is, their tags are unknown by the terminal) shall not be stored, but records containing such data objects may still participate in their entirety in offline data authentication, depending upon the coding of the AFL. All mandatory data objects shall be present in the card. If any mandatory data objects are not present, the terminal shall terminate the transaction. Redundant primitive data objects are not permitted. If the terminal encounters more than one occurrence of a single primitive data object while reading data from the ICC, the transaction shall be terminated. Proprietary data files may or may not conform to this specification. Records in proprietary files may be represented in the AFL and may participate in offline data authentication if they are readable without conditions by the READ RECORD command coded according to the Card Specification. Otherwise, the reading and processing of proprietary files is beyond the scope of this specification.

6.3 Offline Data Authentication Purpose: Offline data authentication is performed as specified in Book 2. This specification describes how it is determined whether offline data authentication will be performed, what kind of authentication will be performed, and how the success or failure of authentication affects the transaction flow and data recorded in the TVR and TSI. Conditions of Execution: Availability of data in the ICC to support offline data authentication is optional; its presence is indicated in the Application Interchange Profile. If both the terminal and the ICC support offline data authentication, the terminal shall perform this function. Depending on the capabilities of the card and the

46


December, 2000

terminal, either offline static data authentication or dynamic data authentication may be performed but not both. If both of the following are true, the terminal shall perform the Combined Dynamic Data Authentication/Application Cryptogram Generation as specified in Book 2: •

The Application Interchange Profile indicates that the card supports the Combined Dynamic Data Authentication/Application Cryptogram Generation.

•

The terminal supports the Combined Dynamic Data Authentication/Application Cryptogram Generation.

If all of the following are true, the terminal shall perform offline dynamic data authentication as specified in Book 2: •

The Application Interchange Profile indicates that the card supports offline dynamic data authentication.

•

The terminal supports offline dynamic data authentication.

•

Either the card or terminal (or both) does not support Combined Dynamic Data Authentication/Application Cryptogram Generation.

If all of the following are true, the terminal shall perform offline static data authentication as specified in the Card Specification: •

The Application Interchange Profile indicates that the card supports offline static data authentication.

•

The terminal supports offline static data authentication.

•

Either the card or the terminal (or both) does not support offline dynamic data authentication

•

Either the card or terminal (or both) does not support Combined Dynamic Data Authentication/Application Cryptogram Generation.

If neither offline static data authentication nor offline dynamic data authentication is performed, the terminal shall set the ‘Offline data authentication was not performed’ bit to ‘1’ in the TVR. Sequence of Execution: The terminal shall perform offline data authentication in any order after Read Application Data but before completion of the terminal action analysis. Description: Offline static data authentication authenticates static data put into the card by the issuer. Offline dynamic data authentication authenticates ICC-resident data, data from the terminal, and the card itself.

December, 2000


47

Input to the authentication process is formed from the records identified by the AFL, followed by the data elements identified by the optional Static Data Authentication Tag List (tag ‘9F4A’). Only those records identified in the AFL as participating in offline data authentication are to be processed. Records are processed in the same sequence in which they appear within AFL entries. The records identified by a single AFL entry are to be processed in record number sequence. The first record begins the input for the authentication process, and each succeeding record is concatenated at the end of the previous record. The data from each record to be included in the offline data authentication input depends upon the SFI of the file from which the record was read. •

For files with SFI in the range 1 to 10, the record tag (‘70’) and the record length are excluded from the offline data authentication process. All other data in the data field of the response to the READ RECORD command (excluding SW1 SW2) is included.

•

For files with SFI 11-30, all data in the data field (excluding SW1 SW2) is included.

The bytes of the record are included in the concatenation in the order in which they appear in the command response. After all records identified by the AFL have been processed, the Static Data Authentication Tag List is processed, if it exists. If the Static Data Authentication Tag List exists, it shall contain only the tag for the Application Interchange Profile. The tag must represent the AIP available in the current application. The value field of the AIP is to be concatenated to the current end of the input string. The tag and length of the AIP are not included in the concatenation. Building of the input list for offline data authentication is considered the first step in the offline data authentication process. If the input cannot be built because of a violation of one of the above rules but offline data authentication should be performed according to the ‘Conditions of Execution’ above, offline data authentication shall be considered to have been performed and to have failed; that is, the terminal shall set to ‘1’ the ‘Offline data authentication was performed’ bit in the TSI and the appropriate ‘Offline static data authentication failed’ or ‘Offline dynamic authentication failed’ bit shall be set in the TVR. See Book 2 for additional steps to be performed for offline data authentication. If offline static data authentication is performed but is unsuccessful, the ‘Offline static data authentication failed’ bit shall be set to ‘1’ in the TVR, otherwise it shall be set to ‘0’. If offline dynamic data authentication is performed but is unsuccessful, the ‘Offline dynamic data authentication failed’ bit shall be set to ‘1’ in the TVR, otherwise it shall be set to ‘0’.

48


December, 2000

If the Combined Dynamic Data Authentication/Application Cryptogram Generation is performed but is unsuccessful, the ‘Combined Dynamic Data Authentication/Application Cryptogram Generation‘ bit shall be set to ‘1’ in the TVR, otherwise it shall be set to ‘0’. Upon completion of the offline data authentication function, the terminal shall set to ‘1’ the ‘Offline data authentication was performed’ bit in the TSI.

6.4 Processing Restrictions Purpose: The purpose of the processing restrictions function is to determine the degree of compatibility of the application in the terminal with the application in the ICC and to make any necessary adjustments, including possible rejection of the transaction. Conditions of Execution: The terminal shall always execute this function. Sequence of Execution: Functions described here may be performed at any time after Read Application Data and prior to completion of the terminal action analysis. Description: The processing restrictions function is described as comprising the following compatibility checks: •

Application Version Number

•

Application Usage Control

•

Application Effective/Expiration Dates Checking

6.4.1 Application Version Number The application within both the terminal and the ICC shall maintain an Application Version Number assigned by the payment system. The terminal shall use the version number in the ICC to ensure compatibility. If the Application Version Number is not present in the ICC, the terminal shall presume the terminal and ICC application versions are compatible, and transaction processing shall continue. If the Application Version Number is present in the ICC, it shall be compared to the Application Version Number maintained in the terminal. If they are different, the ‘ICC and terminal have different application versions’ bit shall be set to ‘1’ in the TVR.

6.4.2 Application Usage Control The Application Usage Control indicates restrictions limiting the application geographically or to certain types of transactions. If this data object is present, the terminal shall make the following checks:

December, 2000


49

•

If the transaction is being conducted at an ATM, the ‘Valid at ATMs’ bit must be on in Application Usage Control.

•

If the transaction is not being conducted at an ATM, the ‘Valid at terminals other than ATMs’ bit must be on in Application Usage Control.

If the Application Usage Control and Issuer Country Code are both present in the ICC, the terminal shall make the following checks: •

If the Transaction Type indicates that this is a cash transaction and the Issuer Country Code matches the Terminal Country Code, the ‘Valid for domestic cash transactions’ bit must be on in Application Usage Control.

•

If the Transaction Type indicates that this is a cash transaction and the Issuer Country Code does not match the Terminal Country Code, the ‘Valid for international cash transactions’ bit must be on in Application Usage Control.

•

If the Transaction Type indicates a purchase of goods and the Issuer Country Code matches the Terminal Country Code, the ‘Valid for domestic goods’ bit must be on in Application Usage Control.

•

If the Transaction Type indicates a purchase of goods and the Issuer Country Code does not match the Terminal Country Code, the ‘Valid for international goods’ bit must be on in Application Usage Control.

•

If the Transaction Type indicates a purchase of services and the Issuer Country Code matches the Terminal Country Code, the ‘Valid for domestic services’ bit must be on in Application Usage Control.

•

If the Transaction Type indicates a purchase of services and the Issuer Country Code does not match the Terminal Country Code, the ‘Valid for international services’ bit must be on in Application Usage Control.

•

If the transaction has a cashback amount and the Issuer Country Code matches the Terminal Country Code, the ‘Domestic cashback allowed’ bit must be on in Application Usage Control.

•

If the transaction has a cashback amount and the Issuer Country Code does not match the Terminal Country Code, the ‘International cashback allowed’ bit must be on in Application Usage Control.

If any of the above tests fail, the ‘Requested service not allowed for card product’ bit shall be set to ‘1’ in the TVR.

6.4.3 Application Effective/Expiration Dates Checking If the Application Effective Date is present in the ICC, the terminal shall check that the current date is greater than or equal to the Application Effective Date. If it is not, the ‘Application not yet effective’ bit shall be set to ‘1’ in the TVR. The terminal shall check that the current date is less than or equal to the Application

50


December, 2000

Expiration Date. If it is not, the ‘Expired application’ bit shall be set to ‘1’ in the TVR.

6.5 Cardholder Verification Purpose: Cardholder verification is performed to ensure that the person presenting the ICC is the person to whom the application in the card was issued. Conditions of Execution: Ability of the ICC to support at least one cardholder verification method is indicated in the Application Interchange Profile. If this bit is set to ‘1’, the terminal shall use the cardholder verification related data in the ICC to determine whether one of the issuer-specified cardholder verification methods (CVMs) shall be executed. This process is described below. Sequence of Execution: This function may be performed any time after Read Application Data and before completion of the terminal action analysis. Description: The CVM List (tag ‘8E’) is a composite data object consisting of the following: 1. An amount field (4 bytes, binary format), referred to as ‘X’ in the CVM Condition Codes (see Annex C.3 - Cardholder Verification Rule Format). ‘X’ is expressed in the Application Currency Code with implicit decimal point. For example, 123 (hexadecimal ‘7B’) represents £1.23 when the currency code is ‘826’. 2. A second amount field (4 bytes, binary format), referred to as ‘Y’ in the CVM Condition Codes (see Annex C.3 - Cardholder Verification Rule Format). ‘Y’ is expressed in Application Currency Code with implicit decimal point. For example, 123 (hexadecimal ‘7B’) represents £1.23 when the currency code is ‘826’. 3. A variable-length list of two-byte data elements called Cardholder Verification Rules (CVRs). Each CVR describes a CVM and the conditions under which that CVM should be applied (see Annex C.3 - Cardholder Verification Rule Format). If the CVM List is not present in the ICC, the terminal shall terminate cardholder verification without setting the ‘Cardholder verification was performed’ bit in the TSI. If the CVM List is present in the ICC, the terminal shall process each rule in the order in which it appears in the list according to the following specifications. Cardholder verification is completed when any one CVM is successfully performed or when the list is exhausted.

December, 2000


51

If any of the following are true: •

The conditions expressed in the second byte of a CVR are not satisfied, or

•

The ICC data required by the condition (for example, the Application Currency Code) is not present, or

•

The CVM Condition Code is outside the range of codes understood by the terminal (which might occur if the terminal application program is at a different version level than the ICC application),

the terminal shall bypass the rule and proceed to the next. If there are no more CVRs in the list, cardholder verification has not been successful, and the terminal shall set the ‘Cardholder verification was not successful’ bit to ‘1’ in the TVR. If the conditions expressed in the second byte of a CVR are satisfied, the terminal shall attempt to perform the CVM if the CVM code is one of those listed in Annex A or is otherwise understood by the terminal. If the conditions expressed in the second byte of a CVR are satisfied, but the CVM is not among those listed and is not understood by the terminal, the terminal shall set the ‘Unrecognised CVM’ bit to ‘1’ in the TVR. If the CVM is performed successfully, cardholder verification is complete and successful. Otherwise, the terminal shall then examine b7 of byte 1 of the CVM field. If b7 is set to ‘1’, processing continues with the next CVR, if one is present. If b7 is set to ‘0’, or there are no more CVRs in the list, the terminal shall set the ‘Cardholder verification was not successful’ bit to ‘1’ in the TVR and cardholder verification is complete. When cardholder verification is completed, the ‘Cardholder verification was performed’ bit in TSI shall be set to ‘1’.

6.5.1 Offline PIN Processing This section applies to the verification by the ICC of a plaintext or enciphered PIN presented by the terminal. If an offline PIN is the selected CVM as determined by the above process, offline PIN processing may not be successfully performed for any one of the following reasons: •

7

The terminal does not support offline PIN7. In this case, the terminal shall set to ‘1’ the ‘PIN entry required and PIN pad not present or not working’ bit in the TVR.

This means that the terminal does not support either offline plaintext PIN verification or offline enciphered PIN verification. If the terminal supports at least one of these functions, it is considered to support offline PIN for the purposes of setting the TVR bits.

52


December, 2000

•

The terminal supports offline PIN, but the PIN pad is malfunctioning. In this case, the terminal shall set to ‘1’ the ‘PIN entry required and PIN pad not present or not working’ bit in the TVR.

•

The terminal bypassed PIN entry at the direction of either the merchant or the cardholder8. In this case, the ‘PIN entry required, PIN pad present, but PIN was not entered’ bit shall be set to ‘1’ in the TVR. The terminal shall consider this CVM unsuccessful, shall not set the CVM Results, and shall continue cardholder verification processing in accordance with the card’s CVM List.

•

The PIN is blocked upon initial use of the VERIFY command (the ICC returns SW1 SW2 = ‘6983’ or ‘6984’ in response to the VERIFY command). In this case, the ‘PIN Try Limit exceeded’ bit shall be set to ‘1’ in the TVR.

•

The number of remaining PIN tries is reduced to zero (indicated by an SW1 SW2 of ‘63C0’ in the response to the VERIFY command). In this case, the ‘PIN Try Limit exceeded’ bit shall be set to ‘1’ in the TVR.

The only case in which offline PIN processing is considered successful is when the ICC returns an SW1 SW2 of ‘9000’ in response to the VERIFY command.

6.5.2 Online PIN Processing If online PIN processing is a required CVM as determined by the above process, the processing may not be successfully performed for any one of the following reasons: •

The terminal does not support online PIN. In this case, the terminal shall set to ‘1’ the ‘PIN entry required and PIN pad not present or not working’ bit in the TVR.

•

The terminal supports online PIN, but the PIN pad is malfunctioning. In this case, the terminal shall set to ‘1’ the ‘PIN entry required and PIN pad not present or not working’ bit in the TVR.

•

The terminal bypassed PIN entry at the direction of either the merchant or the cardholder. In this case, the ‘PIN entry required, PIN pad present, but PIN was not entered’ bit shall be set to ‘1’ in the TVR.

If the online PIN is successfully entered, the terminal shall set to ‘1’ the ‘Online PIN entered’ bit in the TVR. In this case, cardholder verification is considered successful and complete. 8

Especially for a new cardholder or during conversion to PINs, it is likely that a cardholder will realize that he or she does not know the PIN. In this case, it is better to bypass PIN processing with an indication to the issuer of the circumstances than it is to either terminate the transaction or try numbers until the PIN try count is exhausted. If the transaction goes online, the issuer can decide whether to accept the transaction without the PIN.

December, 2000


53

6.5.3 Signature Processing If a (paper) signature is a required CVM as determined by the above process, the terminal shall determine success based upon the terminal’s capability to support the signature process (see complementary payment systems documentation for additional information). If the terminal is able to support signature, the process is considered successful, and cardholder verification is complete.

6.5.4 Combination CVMs Some CVMs require multiple verification methods (for example, offline PIN plus signature). For these CVMs, all methods in the CVM must be successful for cardholder verification to be considered successful.

6.6 Terminal Risk Management Purpose: Terminal risk management is that portion of risk management performed by the terminal to protect the acquirer, issuer, and system from fraud. It provides positive issuer authorisation for high-value transactions and ensures that transactions initiated from ICCs go online periodically to protect against threats that might be undetectable in an offline environment. The result of terminal risk management is the setting of appropriate bits in the TVR. Conditions of Execution: Terminal risk management shall be performed if the ‘Terminal risk management is supported’ bit is set to ‘1’ in the Application Interchange Profile. Random transaction selection need not be performed by a terminal with no online capability. If terminal risk management is not performed, sections 6.6.1 through 6.6.3 do not apply. Sequence of Execution: Terminal risk management may be performed at any time after Read Application Data but before issuing the first GENERATE AC command. Description: Terminal risk management consists of: •

Floor limit checking

•

Random transaction selection

•

Velocity checking

6.6.1 Floor Limits To prevent split sales, the terminal may have a transaction log of approved transactions stored in the terminal consisting of at least the Application PAN and transaction amount and possibly the Application PAN Sequence Number and Transaction Date. The number of transactions to be stored and maintenance of

54


December, 2000

the log is outside the scope of this specification, although to prevent split sales the number of transactions stored may be quite small. During terminal risk management floor limit checking, the terminal checks the transaction log (if available) to determine if there is a log entry with the same Application PAN, and, optionally, the same Application PAN Sequence Number. If there are several log entries with the same PAN, the terminal selects the most recent entry. The terminal adds the Amount, Authorised for the current transaction to the amount stored in the log for that PAN to determine if the sum exceeds the Terminal Floor Limit. If the sum is greater than or equal to the Terminal Floor Limit, the terminal sets the ‘Transaction exceeds floor limit’ bit to ‘1’ in the TVR. If the terminal does not have a transaction log available or if there is no log entry with the same PAN, the Amount, Authorised is compared to the appropriate floor limit. If the amount authorised is equal to or greater than the floor limit, the ‘Transaction exceeds floor limit’ bit is set to ‘1’ in the TVR.

6.6.2 Random Transaction Selection For each application the relevant payment system specifies, in addition to the floor limit: •

Target Percentage to be Used for Random Selection (in the range of 0 to 99)

•

Threshold Value for Biased Random Selection (which must be zero or a positive number less than the floor limit)

•

Maximum Target Percentage to be Used for Biased Random Selection (also in the range of 0 to 99 but at least as high as the previous Target Percentage for Random Selection). This is the desired percentage of transactions ‘just below’ the floor limit that will be selected by this algorithm.

Any transaction with a transaction amount less than the Threshold Value for Biased Random Selection will be subject to selection at random without further regard for the value of the transaction. The terminal shall generate a random number in the range of 1 to 99. If this random number is less than or equal to the Target Percentage to be Used for Random Selection, the transaction shall be selected. Any transaction with a transaction amount equal to or greater than the Threshold Value for Biased Random Selection but less than the floor limit will be subject to selection with bias toward sending higher value transactions online more frequently (biased random selection). For these transactions, the terminal shall compare its generated random number against a Transaction Target Percent, which is a linear interpolation of the target percentages provided by the payment system (Target Percentage to be Used for Random Selection, and

December, 2000


55

Maximum Target Percentage to be Used for Biased Random Selection).9 If the random number is less than or equal to the Transaction Target Percent, the transaction shall be selected. The probability of selection as a function of the transaction amount may be charted as shown in Figure II-4:

1

0 Biased Selection Threshold

Floor Limit

Figure II- 4 - Random Transaction Selection Example

If the transaction is selected through the process described in this section, the ‘Transaction selected randomly for online processing’ bit shall be set to ‘1’ in the TVR.

6.6.3 Velocity Checking10 If both the Lower Consecutive Offline Limit (tag ‘9F14’) and Upper Consecutive Offline Limit (tag ‘9F23’) exist, the terminal shall perform velocity checking as 9

The Transaction Target Percent is calculated as follows: Interpolation factor =

Transaction Target Percent =

Amount, Authorised − Threshold Value Floor Limit − Threshold Value

((Maximum Target Percent - Target Percent ) × Interpolation factor ) + Target Percent

10

The purpose of velocity checking is to allow an issuer to request that, after a certain number of consecutive offline transactions (the Lower Consecutive Offline Limit), transactions should be completed online. However, if the terminal is incapable of going online, transactions may still be completed offline until a second (Upper Consecutive Offline Limit) limit is reached. After the upper limit is reached, the recommendation of the issuer might be to reject any transaction that cannot be completed online. Once a transaction has been completed online with successful issuer authentication, the count begins anew, so that transactions may be processed offline until the lower limit is again reached.

56


December, 2000

described in this section. If either of these data objects is not present in the ICC application, the terminal shall skip this section. The ATC and Last Online ATC Register shall be read from the ICC using GET DATA commands. If either of the required data objects are not returned by the ICC in response to the GET DATA command, the terminal shall: • •

Set both the ‘Lower consecutive offline limit exceeded’ and the ‘Upper consecutive offline limit exceeded’ bits to ‘1’ in the TVR. Not set the ‘New card’ indicator in the TVR.

•

End velocity checking for this transaction.

If the required data objects are available, the terminal shall compare the difference between the ATC and the Last Online ATC Register with the Lower Consecutive Offline Limit to see if the limit has been exceeded. If the difference is equal to the Lower Consecutive Offline Limit, this means that the limit has not yet been exceeded. If the limit has been exceeded, the terminal shall set the ‘Lower consecutive offline limit exceeded’ bit to ‘1’ in the TVR and also compare the difference with the Upper Consecutive Offline Limit to see if the upper limit has been exceeded. If it has, the terminal shall set the ‘Upper consecutive offline limit exceeded’ bit to ‘1’ in the TVR. The terminal shall also check the Last Online ATC Register for a zero value. If it is zero, the terminal shall set the ‘New card’ bit to ‘1’ in the TVR. Upon completion of terminal risk management, the terminal shall set to ‘1’ the ‘Terminal risk management was performed’ bit in the TSI.

6.7 Terminal Action Analysis Purpose: Once terminal risk management and application functions related to a normal offline transaction have been completed, the terminal makes the first decision as to whether the transaction should be approved offline, declined offline, or transmitted online. If the outcome of this decision process is to proceed offline, the terminal issues a GENERATE AC command to ask the ICC to return a TC. If the outcome of the decision is to go online, the terminal will issue a GENERATE AC command to ask the ICC for an Authorisation Request Cryptogram (ARQC). If the decision is to reject the transaction, the terminal will issue a GENERATE AC to ask for an Application Authentication Cryptogram (AAC). An offline decision made here is not final. If the terminal asks for a TC from the ICC, the ICC, as a result of card risk management, may return an ARQC or AAC. Conditions of Execution: The terminal action analysis function is always performed.

December, 2000


57

Sequence of Execution: The terminal action analysis function is performed after terminal risk management and cardholder- and merchant-entered transaction data has been completed. It shall be performed prior to the first use of the GENERATE AC command. The Issuer Action Code - Default and Terminal Action Code - Default processing described below shall also be performed after online processing is attempted in the case where the terminal was unable to process the transaction online. The terminal action analysis function may be executed at several places during a transaction to eliminate the need for unnecessary processing. If any processing results in the setting of a bit in the TVR (for example, failure of cardholder verification), it may be desirable to perform this function immediately to determine whether the transaction should be rejected offline based upon the issuer’s parameters in the ICC or the acquirer’s parameters in the terminal. Recognition of such a decision early in processing may allow the terminal to avoid prolonging a transaction that will ultimately be rejected. Multiple executions of this decision process is optional on the part of the terminal. Description: The terminal shall make a preliminary decision to reject the transaction, complete it online, or complete it offline based upon the TVR, issuer action preferences, and acquirer action preferences according to the method described in this section. The ICC contains (optionally) three data elements to reflect the issuer’s selected action to be taken based upon the content of the TVR. Each of the three data elements has defaults specified here in case any of these data elements are absent from the ICC. The three data elements are: •

Issuer Action Code – Denial

•

Issuer Action Code - Online

•

Issuer Action Code - Default

Collectively, these three data objects are termed the Issuer Action Codes. The purpose of each is described in this section below. The format of each is identical and mirrors the TVR. Each has one bit corresponding to each bit in the TVR, and the Issuer Action Code bit specifies an action to be taken if the corresponding bit in the TVR is set to ‘1’. Thus, the size and format of each of the Issuer Action Codes is identical to the TVR. Similarly, the terminal may contain three data elements to reflect the acquirer’s selected action to be taken based upon the content of the TVR. These data elements are: •

Terminal Action Code - Denial

•

Terminal Action Code - Online

58 •


December, 2000

Terminal Action Code - Default

Collectively, these three data objects are termed the Terminal Action Codes. The purpose of each is described in this section below. The format of each is identical and mirrors the TVR. Each has one bit corresponding to each bit in the TVR, and the Terminal Action Code bit specifies an action to be taken if the corresponding bit in the TVR is set to ‘1’. Thus, the size and format of each of the Terminal Action Codes is identical to the TVR and to the Issuer Action Codes. The existence of each of the Terminal Action Codes is optional. In the absence of any Terminal Action Code, a default value consisting of all bits set to ‘0’ is to be used in its place. However, it is strongly recommended that as a minimum, the Terminal Action Code - Online and Terminal Action Code - Default should be included with the bits corresponding to ‘Offline data authentication was not performed’, ‘Offline static data authentication failed’, and ‘Offline dynamic data authentication failed’ set to ‘1’.11 Processing of the action codes is done in pairs, that is, the Issuer Action Code Denial is processed together with the Terminal Action Code - Denial, the Issuer Action Code - Online is processed together with the Terminal Action Code Online, and the Issuer Action Code - Default is processed together with the Terminal Action Code - Default. Processing of the action codes shall be performed in the order specified here. If the Issuer Action Code - Denial does not exist, a default value with all bits set to ‘0’ is to be used. Together, the Issuer Action Code - Denial and the Terminal Action Code - Denial specify the conditions that cause denial of a transaction without attempting to go online. If either data object exists, the terminal shall inspect each bit in the TVR. For each bit in the TVR that has a value of ‘1’, the terminal shall check the corresponding bits in the Issuer Action Code - Denial and the Terminal Action Code - Denial. If the corresponding bit in either of the action codes is set to ‘1’, it indicates that the issuer or the acquirer wishes the transaction to be rejected offline. In this case, the terminal shall issue a GENERATE AC command to request from the ICC an AAC. This AAC may be presented to the issuer to prove card presence during this transaction, but details of handling a rejected transaction are outside the scope of this specification. If the Issuer Action Code - Online is not present, a default value with all bits set to ‘1’ shall be used in its place. Together, the Issuer Action Code - Online and the Terminal Action Code - Online specify the conditions that cause a transaction to be completed online. These data objects are meaningful only for terminals capable of online processing. Offline-only terminals may skip this test and proceed to checking the Issuer Action Code - Default and Terminal Action Code Default, described below. For a terminal capable of online processing, if the terminal has not already decided to reject the transaction as described above, the This protects against a fraudulent card with all the bits in the Issuer Action Code set to ‘0’. Without this protection, such a card could be created with no possibility of going online or declining transactions. All transactions would be approved offline.

11

December, 2000


59

terminal shall inspect each bit in the TVR. For each bit in the TVR that has a value of ‘1’, the terminal shall check the corresponding bits in both the Issuer Action Code - Online and the Terminal Action Code - Online. If the bit in either of the action codes is set to ‘1’, the terminal shall complete transaction processing online and shall issue a GENERATE AC command requesting an ARQC from the ICC. If the Issuer Action Code - Default does not exist, a default value with all bits set to ‘1’ shall be used in its place. Together, the Issuer Action Code - Default and the Terminal Action Code - Default specify the conditions that cause the transaction to be rejected if it might have been approved online but the terminal is for any reason unable to process the transaction online. The Issuer Action Code - Default and the Terminal Action Code - Default are used only if the Issuer Action Code - Online and the Terminal Action Code - Online were not used (for example, in case of an offline-only terminal) or indicated a desire on the part of the issuer or the acquirer to process the transaction online but the terminal was unable to go online. If the terminal has not already rejected the transaction and the terminal is for any reason unable to process the transaction online, the terminal shall use this code to determine whether to approve or reject the transaction offline. If any bit in Issuer Action Code - Default or the Terminal Action Code - Default and the corresponding bit in the TVR are both set to ‘1’, the transaction shall be rejected and the terminal shall request an AAC to complete processing. If no such condition appears, the transaction may be approved offline, and a GENERATE AC command shall be issued to the ICC requesting a TC. If Combined DDA/AC Generation is to be performed and the ICC’s CDOL1 does not include the tag for the Terminal Capability Profile, the terminal shall set the bit for Combined DDA/AC Generation Requested in the GENERATE AC command to ‘1’.

6.8 Card Action Analysis Purpose: An ICC may perform its own risk management to protect the issuer from fraud or excessive credit risk. Details of card risk management algorithms within the ICC are specific to the issuer and are outside the scope of this specification, but as a result of the risk management process, an ICC may decide to complete a transaction online or offline or request a referral or reject the transaction. The ICC may also decide that an advice message should be sent to the issuer to inform the issuer of an exceptional condition. Conditions of Execution: The card online/offline decision is specified by its response to the GENERATE AC command. Therefore, this section applies to all transactions. Whether the ICC performs any risk management tests is transparent to the terminal and outside the scope of this specification. Sequence of Execution: The card action analysis process is performed when the terminal issues the GENERATE AC command for a given transaction.

60


December, 2000

Description: The result of risk management performed by the ICC is a decision for one of the following actions to be taken by the terminal: • Approve the transaction offline. This option is available to the ICC only if the terminal has made a preliminary decision to complete the transaction offline, as described in section 6.7. •

Complete the transaction online.

•

Request a referral.

•

Reject the transaction.

The decision by the ICC is made known to the terminal by returning a TC, an ARQC, an AAR, or an AAC to the terminal in response to a GENERATE AC command, as described in section 2.5.5. Upon the completion of the card action analysis function, the terminal shall set to ‘1’ the ‘Card risk management was performed’ bit in the TSI.

6.8.1 Terminal Messages for an AAC An AAC returned by the card indicates either a rejection of the specific transaction or a restriction that disallows use of the card in the environment of the transaction (for example, the card application may be restricted only to specific merchant categories). In both cases, the card disapproves the transaction, but the terminal may choose to display different messages in the two cases. The card may optionally distinguish the cases by the use of the code returned in the Cryptogram Information Data (see the GENERATE AC command in section 2.5.5). If an AAC is returned with b3-b1 = ‘001’ in the Cryptogram Information Data, the AAC was returned due to card restrictions.

6.8.2 Terminal Messages for a TC and ARQC The ICC determines if the transaction is eligible for combined DDA/AC generation using one of the following methods: 1. When the Terminal Capabilities Profile is included in the CDOL data, the ICC considers the transaction eligible for combined DDA/AC generation if the Combined Dynamic Data Authentication/Application Cryptogram Generation bit in the Terminal Capabilities Profile is ‘1’ and Combined DDA/Generate AC bit in the Application Interchange Profile is ‘1’. 2. When the Terminal Capabilities Profile is not included in the CDOL data, the ICC considers the transaction eligible for combined DDA/AC generation if Combined DDA/AC Generation Requested bit in the GENERATE AC command is ‘1’.

December, 2000


61

If the transaction is eligible for combined DDA/AC generation and the ICC response is an offline approval (TC) or an online request (ARQC), the ICC shall return the GENERATE AC response in a public key envelope as specified in Book 2 Section 6.6.

6.8.3 Advice Messages The issuer may wish for an advice message, separate from either an authorisation request or a clearing message, to be sent in certain exception cases. (Currently, the only identified such case is ‘PIN Try Limit exceeded’, but allowance has been made for the addition of other cases later; see ‘Coding of Cryptogram Information Data’ in the GENERATE AC command in the Card Specification). If b4 of the Cryptogram Information Data is ‘1’, the terminal shall format and send an advice message. Further information may be found in complementary payment system documentation and in Book 4.

6.9 Online Processing Purpose: Online processing is performed to ensure that the issuer can review and authorise or reject transactions that are outside acceptable limits of risk defined by the issuer, the payment system, or the acquirer. Conditions of Execution: Online processing shall be performed if the ICC returns an ARQC in response to the first GENERATE AC command for the transaction. Sequence of Execution: The online processing function is performed when the terminal receives an ARQC in response to the first GENERATE AC command. Description: In general, online processing is the same as today’s online processing of magnetic stripe transactions and is not described here. This section is limited to the additional online processing provided in an ICC environment that is not available in a magnetic stripe environment. The ARQC may be sent in the authorisation request message.12 The authorisation response message from the issuer may contain the Issuer Actions performed by the acquirer or issuer systems are outside the scope of this specification. However, an explanation of what is expected to take place at the issuer may be useful for clarity. The ARQC is a cryptogram generated by the card from transaction data using an issuer key stored in the card and known at the issuer authorisation system. The issuer uses this key to authenticate the ARQC and thereby authenticate the card. This process is termed ‘online card authentication’ or simply ‘card authentication’.

12

62


December, 2000

Authentication Data (tag ‘91’). If the Issuer Authentication Data is received in the authorisation response message and the Application Interchange Profile indicates that the ICC supports issuer authentication, the Issuer Authentication Data shall be sent to the ICC in the EXTERNAL AUTHENTICATE command. If the ICC responds with SW1 SW2 other than ‘9000’, the ‘Issuer authentication was unsuccessful’ bit shall be set to ‘1’ in the TVR. If the Issuer Authentication Data is received but the Application Interchange Profile indicates that the ICC does not support issuer authentication, this indicates that the ICC has combined the issuer authentication function with the GENERATE AC command. In this case, or if no Issuer Authentication Data is received, the terminal shall not execute the EXTERNAL AUTHENTICATE command. The ICC shall permit at most one EXTERNAL AUTHENTICATE command in a transaction. If the terminal issues more than one, the second and all succeeding EXTERNAL AUTHENTICATE commands shall end with SW1 SW2 = ‘6985’. Upon completion of online processing, if the EXTERNAL AUTHENTICATE command was sent to the card by the terminal, the terminal shall set to ‘1’ the ‘Issuer authentication was performed’ bit in the TSI.

6.10 Issuer-to-Card Script Processing Purpose: An issuer may provide command scripts to be delivered to the ICC by the terminal to perform functions that are not necessarily relevant to the current transaction but are important for the continued functioning of the application in the ICC. Multiple scripts may be provided with an authorisation response, and each may contain any number of Issuer Script Commands. Script processing is provided to allow for functions that are outside the scope of this specification but are nonetheless necessary.13 A script may contain Issuer Script Commands not known to the terminal, but the terminal shall deliver each command to the ICC individually according to this specification. Conditions of Execution: None. Subsequent to card authentication, the issuer may generate a cryptogram on selected data included in the authorisation response or already known to the card. This cryptogram is sent to the terminal in the authorisation response as part of the Issuer Authentication Data. The terminal provides the Issuer Authentication Data to the ICC in the EXTERNAL AUTHENTICATE command or the second GENERATE AC command, as described in the Card Specification. The ICC may use the Issuer Authentication Data to authenticate that the response message originated from the issuer. 13 An example might be unblocking of an offline PIN, which might be done differently by various issuers or payment systems.

December, 2000


63

Sequence of Execution: Two separate script tags are defined that are available for use by the issuer. Issuer scripts with tag ‘71’ shall be processed prior to issuing the final GENERATE AC command. Issuer scripts using tag ‘72’ shall be processed after issuing the final GENERATE AC command. Description: An Issuer Script is a constructed data object (tag ‘71’ or ‘72’) containing (optionally) a Script Identifier and a sequence of Issuer Script Command APDUs to be delivered serially to the ICC. The Script Identifier is optional and is not interpreted by the terminal; it is meaningful only to the issuer. Figure II – 5 and Figure II - 6 illustrate an Issuer Script containing a Script Identifier and three commands. T ‘71’ or ‘72’

L L(∑data, including Script ID, tags, and lengths)

T ‘9F18’

L ‘04’

Script ID Identifier (4 bytes)

Commands (see Figure II – 6 – Issuer Script Command Format (Shown with Three Commands))

Figure II - 5- Issuer Script Format

T1 ‘86’

L1 L(V1)

V1 Command

T2 ‘86’

L2 L(V2)

V2 Command

T3 ‘86’

L3 L(V3)

V3 Command

Figure II - 6- Issuer Script Command Format (Shown with Three Commands)

It is possible for multiple Issuer Scripts to be delivered with a single authorisation response. The terminal shall process each Issuer Script in the sequence in which it appears in the authorisation response according to the following rules: •

Issuer Script Commands shall be separated using the BER-TLV coding of the data objects defining the commands (tag ‘86’).

•

Each command will be delivered to the ICC as a command APDU in the sequence in which it appeared in the Issuer Script.

•

The terminal shall examine only SW1 in the response APDU and perform one of the following actions: −

If SW1 indicates either normal processing or a ‘warning’ according to the conventions described in the Card Specification, the terminal shall continue with the next command from the Issuer Script (if any).

64

Functions Used in Transaction Processing −

December, 2000

If SW1 indicates an ‘error’ condition, the processing of the Issuer Script shall be terminated.

If an Issuer Script is processed, the terminal shall set the ‘Script processing was performed’ bit in the TSI to ‘1’. If an error occurred in processing a script, the terminal shall set to ‘1’ either the ‘Script processing failed before final GENERATE AC’ in the TVR if the identifying tag of the failing script was ‘71’ or the ‘Script processing failed after final GENERATE AC’ in the TVR if the tag was ‘72’.

6.11 Completion Purpose: The completion function closes processing of a transaction. Conditions of Execution: The terminal always performs this function unless the transaction is terminated prematurely by error processing. Sequence of Execution: The completion function is always the last function in the transaction processing. (Script processing may be performed after the completion function.) Description: The ICC indicates willingness to complete transaction processing by returning either a TC or an AAC to either the first or second GENERATE AC command issued by the terminal. If the terminal decides to go online, completion shall be done when the second GENERATE AC command is issued. See section 5 for additional information on the use of the GENERATE AC command.

Annexes

December, 2000

Annex A – Data Elements Table

67

Annex A - Data Elements Table Table A-1 defines those data elements that may be used for financial transaction interchange and their mapping onto data objects and files. Name Acquirer Identifier Additional Terminal Capabilities Amount, Authorised (Binary) Amount, Authorised (Numeric) Amount, Other (Binary) Amount, Other (Numeric) Amount, Reference Currency Application Cryptogram Application Currency Code Application Currency Exponent

Description Uniquely identifies the acquirer within each payment system Indicates the data input and output capabilities of the terminal

Source Terminal

Format n 6-11

Template -

Tag ‘9F01’

Length 6

Terminal

b

-

‘9F40’

5

Authorised amount of the transaction (excluding adjustments)

Terminal

b

-

‘81’

4

Authorised amount of the transaction (excluding adjustments)

Terminal

n 12

-

‘9F02’

6

Secondary amount associated with the transaction representing a cashback amount Secondary amount associated with the transaction representing a cashback amount Authorised amount expressed in the reference currency

Terminal

b

-

‘9F04’

4

Terminal

n 12

-

‘9F03’

6

Terminal

b

-

‘9F3A’

4

ICC

b

‘77’ or ‘80’

‘9F26’

8

ICC

n3

‘70’ or ‘77’

‘9F42’

2

ICC

n1

‘70’ or ‘77’

‘9F44’

1

Cryptogram returned by the ICC in response of the GENERATE AC command Indicates the currency in which the account is managed according to ISO 4217 Indicates the implied position of the decimal point from the right of the account represented according to ISO 4217

68

Annex A - Data Elements Table

Name Application Discretionary Data Application Effective Date Application Expiration Date Application File Locator (AFL) Application Identifier (AID) Application Identifier (AID) Application Interchange Profile Application Label Application Preferred Name Application Primary Account Number (PAN) Application Primary Account Number (PAN) Sequence Number Application Priority Indicator

Description Issuer or payment system specified data relating to the application

December, 2000

Source ICC

Format b

Template ‘70’ or ‘77’

Tag ‘9F05’

Length 1-32

Date from which the application may be used

ICC

‘70’ or ‘77’

‘5F25’

3

Date after which application expires

ICC

‘70’ or ‘77’

‘5F24’

3

Indicates the location (SFI, range of records) of the AEFs related to a given application Identifies the application as described in ISO/IEC 7816-5

ICC

n6 YYMMDD n6 YYMMDD var.

‘77’ or ‘80’

‘94’

ICC

b

‘61’

‘4F’

var. up to 252 5-16

Identifies the application as described in ISO/IEC 7816-5

Terminal

b

-

‘9F06’

5-16

Indicates the capabilities of the card to support specific functions in the application

ICC

b

‘77’ or ‘80’

‘82’

2

Mnemonic associated with the AID according to ISO/IEC 7816-5 Preferred mnemonic associated with the AID

ICC

an 1-16

‘61’ or ‘A5’

‘50’

1-16

ICC

an 1-16

‘61’ or ‘A5’

‘9F12’

1-16

Valid cardholder account number

ICC

cn var. up to 19

‘70’ or ‘77’

‘5A’

var. up to 10

Identifies and differentiates cards with the same PAN

ICC

n2

‘70’ or ‘77’

‘5F34’

1

Indicates the priority of a given application or group of applications in a directory

ICC

b

‘61’ or ‘A5’

‘87’

1

December, 2000

Name Application Reference Currency Application Reference Currency Exponent Application Selection Indicator

Application Template Application Transaction Counter (ATC) Application Usage Control Application Version Number Application Version Number Authorisation Code Authorisation Response Code


69

Description 1-4 currency codes used between the terminal and the ICC when the Transaction Currency Code is different from the Application Currency Code; each code is 3 digits according to ISO 4217 Indicates the implied position of the decimal point from the right of the amount, for each of the 1-4 reference currencies represented according to ISO 4217

Source ICC

Format n3


Tag ‘9F3B’

Length 2-8

ICC

N1

‘70 or 77’

‘9F43’

1-4

For an application in the ICC to be supported by an application in the terminal, the Application Selection Indicator indicates whether the associated AID in the terminal must match the AID in the card exactly, including the length of the AID, or only up to the length of the AID in the terminal There is only one Application Selection Indicator per AID supported by the terminal Contains one or more data objects relevant to an application directory entry according to ISO/IEC 7816-5 Counter maintained by the application in the ICC (incrementing the ATC is managed by the ICC)

Terminal

At the discretion of the terminal. The data is not sent across the interface

None

None

See format

ICC

b

‘70’ or ‘77’

‘61’

ICC

b

‘77’ or ‘80’

‘9F36’

var. up to 252 2

ICC

b

‘70’ or ‘77’

‘9F07’

2

ICC

b

‘70’ or ‘77’

‘9F08’

2

Terminal

b

-

‘9F09’

2

Issuer

an 6

-

‘89’

6

Issuer/ Terminal

an 2

-

‘8A’

2

Indicates issuer's specified restrictions on the geographic usage and services allowed for the application Version number assigned by the payment system for the application Version number assigned by the payment system for the application Value generated by the issuer for an approved transaction Code that defines the disposition of a message

70


Name Card Risk Management Data Object List 1 (CDOL1) Card Risk Management Data Object List 2 (CDOL2) Cardholder Name Cardholder Name Extended Cardholder Verification Method (CVM) List Cardholder Verification Method (CVM) Results Certification Authority Public Key Check Sum

Certification Authority Public Key Exponent Certification Authority Public Key Index

December, 2000

Description List of data objects (tag and length) to be passed to the ICC in the first GENERATE AC command

Source ICC

Format b


Tag ‘8C’

Length var. up to 252

List of data objects (tag and length) to be passed to the ICC in the second GENERATE AC command

ICC

b

‘70’ or ‘77’

‘8D’

var. up to 252

Indicates cardholder name according to ISO 7813

ICC

ans 2-26

‘70’ or ‘77’

‘5F20’

2-26

Indicates the whole cardholder name when greater than 26 characters using the same coding convention as in ISO 7813 Identifies a method of verification of the cardholder supported by the application

ICC

ans 27-45

‘70’ or ‘77’

‘9F0B’

27-45

ICC

b

‘70’ or ‘77’

‘8E’

var. up to 252

Indicates the results of the last CVM performed

Terminal

b

-

‘9F34’

3

A check value calculated on the concatenation of all parts of the Certification Authority Public Key (RID, Certification Authority Public Key Index, Certification Authority Public Key Modulus, Certification Authority Public Key Exponent) using SHA-1 Value of the exponent part of the Certification Authority Public Key

Terminal

b

--

20

Terminal

b

--

1 or 3

ICC

b

‘8F’

1

Identifies the certification authority's public key in conjunction with the RID

‘70’ or ‘77’

December, 2000

Name Certification Authority Public Key Index Certification Authority Public Key Modulus Command Template Cryptogram Information Data Data Authentication Code Dedicated File (DF) Name Default Dynamic Data Authentication Data Object List (DDOL) Default Transaction Certificate Data Object List (TDOL) Directory Definition File (DDF) Name Directory Discretionary Template


71

Description Identifies the certification authority’s public key in conjunction with the RID

Source Terminal

Format b

Value of the modulus part of the Certification Authority Public Key

Terminal

Identifies the data field of a command message

Tag ‘9F22’

Length 1

b

--

NCA (up to 248)

Terminal

b

‘83’

var.

Indicates the type of cryptogram and the actions to be performed by the terminal

ICC

b

‘9F27’

1

An issuer assigned value that is retained by the terminal during the verification process of the Signed Static Application Data Identifies the name of the DF as described in ISO/IEC 7816-4 DDOL to be used for constructing the INTERNAL AUTHENTICATE command if the DDOL in the card is not present

ICC

b

‘9F45’

2

ICC

b

‘84’

5-16

Terminal

b

--

var.

Terminal

b

--

var.

Identifies the name of a DF associated with a directory

ICC

b

‘61’

‘9D’

5-16

Issuer discretionary part of the directory according to ISO/IEC 7816-5

ICC

var.

‘61’

‘73’

var. up to 252

TDOL to be used for generating the TC Hash Value if the TDOL in the card is not present

Template -

‘77’ or ‘80’

‘6F’

72


Name Dynamic Data Authentication Data Object List (DDOL) Enciphered Personal Identification Number (PIN) Data File Control Information (FCI) Issuer Discretionary Data File Control Information (FCI) Proprietary Template File Control Information (FCI) Template ICC Dynamic Number Integrated Circuit Card (ICC) PIN Encipherment Public Key Certificate

Description List of data objects (tag and length) to be passed to the ICC in the INTERNAL AUTHENTICATE command

December, 2000

Source ICC

Format b

Terminal

b

Issuer discretionary part of the FCI

ICC

var.

Identifies the data object proprietary to this specification in the FCI template according to ISO/IEC 7816-4

ICC

Identifies the FCI template according to ISO/IEC 7816-4

Time-variant number generated by the ICC, to be captured by the terminal ICC PIN Encipherment Public Key certified by the issuer

Transaction PIN enciphered at the PIN pad for online verification or for offline verification if the PIN pad and IFD are not a single integrated device


Tag ‘9F49’

Length up to 252

--

8

‘A5’

‘BF0C’

var. up to 222

var.

‘6F’

‘A5’

var.

ICC

var.

-

‘6F’

var. up to 252

ICC

b

‘9F4C’

2-8

ICC

b

‘9F2D’

NI

‘70’ or ‘77’

December, 2000

Name Integrated Circuit Card (ICC) PIN Encipherment Public Key Exponent Integrated Circuit Card (ICC) PIN Encipherment Public Key Remainder Integrated Circuit Card (ICC) Public Key Certificate Integrated Circuit Card (ICC) Public Key Exponent Integrated Circuit Card (ICC) Public Key Remainder Interface Device (IFD) Serial Number Issuer Action Code - Default Issuer Action Code - Denial


73

Description ICC PIN Encipherment Public Key Exponent used for PIN encipherment

Source ICC

Format b


Tag ‘9F2E’

Length 1 or 3

Remaining digits of the ICC PIN Encipherment Public Key Modulus

ICC

b

‘70’ or ‘77’

‘9F2F’

NPE − NI + 42

ICC Public Key certified by the issuer

ICC

b

‘70’ or ‘77’

‘9F46’

NI

ICC Public Key Exponent used for the verification of the Signed Dynamic Application Data

ICC

b

‘70’ or ‘77’

‘9F47’

1 to 3

Remaining digits of the ICC Public Key Modulus

ICC

b

‘70’ or ‘77’

‘9F48’

NIC − NI + 42

Unique and permanent serial number assigned to the IFD by the manufacturer

Terminal

an 8

-

‘9F1E’

8

Specifies the issuer's conditions that cause a transaction to be rejected if it might have been approved online, but the terminal is unable to process the transaction online Specifies the issuer's conditions that cause the denial of a transaction without attempt to go online

ICC

b

‘70’ or ‘77’

‘9F0D’

5

ICC

b

‘70’ or ‘77’

‘9F0E’

5

74


Name Issuer Action Code - Online Issuer Application Data Issuer Authentication Data Issuer Code Table Index Issuer Country Code Issuer Public Key Certificate Issuer Public Key Exponent Issuer Public Key Remainder Issuer Script Command Issuer Script Identifier Issuer Script Results Issuer Script Template 1 Issuer Script Template 2 Issuer URL

Description Specifies the issuer’s conditions that cause a transaction to be transmitted online Contains proprietary application data for transmission to the issuer in an online transaction Data sent to the ICC for online issuer authentication

December, 2000

Source ICC

Format b


Tag ‘9F0F’

Length 5

ICC

b

‘77’ or ‘80’

‘9F10’

Issuer

b

-

‘91’

var. up to 32 8-16

Indicates the code table according to ISO 8859 for displaying the Application Preferred Name Indicates the country of the issuer according to ISO 3166

ICC

n2

‘A5’

‘9F11’

1

ICC

n3

‘70’ or ‘77’

‘5F28’

2

Issuer public key certified by a certification authority

ICC

b

‘70’ or ‘77’

‘90’

NCA

Issuer public key exponent used for the verification of the Signed Static Application Data and the ICC Public Key Certificate Remaining digits of the Issuer Public Key Modulus

ICC

b

‘70’ or ‘77’

‘9F32’

1 to 3

ICC

b

‘70’ or ‘77’

‘92’

Contains a command for transmission to the ICC

Issuer

b

‘71’ or ‘72’

‘86’

Identification of the Issuer Script

Issuer

b

‘71’ or ‘72’

‘9F18’

NI − NCA + 36 var. up to 261 4

Terminal

b

--

var.

Issuer

b

-

‘71’

var.

Issuer

b

-

‘72’

var.

ICC

ans

‘A5’

‘5F50’

var.

Indicates the result of the terminal script processing Contains proprietary issuer data for transmission to the ICC before the second GENERATE AC command Contains proprietary issuer data for transmission to the ICC after the second GENERATE AC command The URL provides the location of the Issuer’s Library Server on the Internet.

December, 2000

Name Language Preference Last Online Application Transaction Counter (ATC) Register Lower Consecutive Offline Limit Maximum Target Percentage to be used for Biased Random Selection Merchant Category Code Merchant Identifier Merchant Name and Location Message Type Personal Identification Number (PIN) Pad Secret Key


Description 1-4 languages stored in order of preference, each represented by 2 alphabetical characters according to ISO 639 ATC value of the last transaction that went online

75

Source ICC

Format an 2

Template ‘A5’

Tag ‘5F2D’

Length 2-8

ICC

b

-

‘9F13’

2

ICC

b

‘70’ or ‘77’

‘9F14’

1

Terminal

--

--

--

Classifies the type of business being done by the merchant, represented according to ISO 8583:1993 for Card Acceptor Business Code When concatenated with the Acquirer Identifier, uniquely identifies a given merchant Indicates the name and location of the merchant

Terminal

n4

-

‘9F15’

2

Terminal

ans 15

-

‘9F16’

15

Terminal

ans

--

var.

Indicates whether the batch data capture record is a financial record or advice Secret key of a symmetric algorithm used by the PIN pad to encipher the PIN and by the card reader to decipher the PIN if the PIN pad and card reader are not integrated

Terminal

n2

--

1

Terminal

--

--

--

Issuer-specified preference for the maximum number of consecutive offline transactions for this ICC application allowed in a terminal with online capability Value used in terminal risk management for random transaction selection

76


Name Personal Identification Number (PIN) Try Counter Point-of-Service (POS) Entry Mode Processing Options Data Object List (PDOL) Response Message Template Format 1 Response Message Template Format 2 Service Code Short File Identifier (SFI)

Signed Dynamic Application Data Signed Static Application Data Static Data Authentication Tag List

Description Number of PIN tries remaining

December, 2000

Source ICC

Format b

Template -

Tag ‘9F17’

Length 1

Terminal

n2

-

‘9F39’

1

ICC

b

‘A5’

‘9F38’

var.

Contains the data objects (without tags and lengths) returned by the ICC in response to a command

ICC

var.

‘80’

var.

Contains the data objects (with tags and lengths) returned by the ICC in response to a command

ICC

var.

‘77’

var.

Service code as defined on tracks 1 and 2 Identifies the SFI to be used in the commands related to a given AEF or DDF. The SFI data object is a binary field with the three high order bits set to zero.

ICC ICC

n3 b

‘70’ or ‘77’ ‘A5’

‘5F30’ ‘88’

2 1

Digital signature on critical application parameters for dynamic data authentication Digital signature on critical application parameters for static data authentication List of tags of primitive data objects defined in this specification whose value fields are to be included in the Signed Static or Dynamic Application Data

ICC

b

-

‘9F4B’

NIC

ICC

b

‘70’ or ‘77’

‘93’

NI

ICC

--

‘70’ or ‘77’

‘9F4A’

var.

Indicates the method by which the PAN was entered, according to the first two digits of the ISO 8583:1987 POS Entry Mode Contains a list of terminal resident data objects (tags and lengths) needed by the ICC in processing the GET PROCESSING OPTIONS command

December, 2000

Name Target Percentage to be used for Random Selection Terminal Action Code - Default Terminal Action Code - Denial Terminal Action Code - Online Terminal Capabilities Terminal Country Code Terminal Floor Limit Terminal Identification Terminal Risk Management Data Terminal Type Terminal Verification Results Threshold Value for Biased Random Selection


77

Description Value used in terminal risk management for random transaction selection

Source Terminal

Format --

Specifies the acquirer’s conditions that cause a transaction to be rejected if it might have been approved online, but the terminal is unable to process the transaction online Specifies the acquirer’s conditions that cause the denial of a transaction without attempt to go online Specifies the acquirer’s conditions that cause a transaction to be transmitted online Indicates the card data input, CVM, and security capabilities of the terminal Indicates the country of the terminal, represented according to ISO 3166 Indicates the floor limit in the terminal in conjunction with the AID Designates the unique location of a terminal at a merchant

Terminal

Tag --

Length --

b

--

5

Terminal

b

--

5

Terminal

b

--

5

Terminal

b

-

‘9F33’

3

Terminal

n3

-

‘9F1A’

2

Terminal

b

‘9F1B’

4

Terminal

an 8

-

‘9F1C’

8

Application-specific value used by the card for risk management purposes

Terminal

b

-

‘9F1D’

1-8

Indicates the environment of the terminal, its communications capability, and its operational control Status of the different functions as seen from the terminal

Terminal

n2

-

‘9F35’

1

Terminal

b

-

‘95’

5

Terminal

--

--

--

Value used in terminal risk management for random transaction selection

Template

78


Name Track 1 Discretionary Data Track 2 Discretionary Data Track 2 Equivalent Data

Description Discretionary part of track 1 according to ISO/IEC 7813

Source ICC

Format ans


Tag ‘9F1F’

Length var.

Discretionary part of track 2 according to ISO/IEC 7813

ICC

cn

‘70’ or ‘77’

‘9F20’

var.

Contains the data elements of the track 2 according to ISO/IEC 7813, excluding start sentinel, end sentinel, and LRC, as follows:

ICC

b

‘70’ or ‘77’

‘57’

var. up to 19

--

6

Primary Account Number

n, var. up to 19

Field Separator (hex. ‘D’)

b

Expiration Date (YYMM)

n4

Service Code

n3 n, var.

Discretionary Data(define by individual payment systems)

b

Pad with hex. ‘FF’ if needed to ensure whole bytes Transaction Amount Transaction Certificate Data Object List (TDOL) Transaction Certificate (TC) Hash Value

December, 2000

Clearing amount of the transaction, including tips and other adjustments List of data objects (tag and length) to be used by the terminal in generating the TC Hash Value

Terminal

n 12

ICC

b

‘70’ or ‘77’

‘97’

var. up to 252

Result of a hash function specified in Annex F3 of this specification

Terminal

b

-

‘98’

20

December, 2000

Name Transaction Currency Code Transaction Currency Exponent Transaction Date Transaction Personal Identification Number (PIN) Data Transaction Reference Currency Code Transaction Reference Currency Conversion Transaction Reference Currency Exponent Transaction Sequence Counter Transaction Status Information Transaction Time


79

Description Indicates the currency code of the transaction according to ISO 4217 Indicates the implied position of the decimal point from the right of the transaction amount represented according to ISO 4217 Local date that the transaction was authorised

Source Terminal

Format n3

Template -

Tag ‘5F2A’

Length 2

Terminal

n1

-

‘5F36’

1

Terminal

-

‘9A’

3

Data entered by the cardholder for the purpose of the PIN verification

Terminal

n6 YYMMDD b

-

‘99’

var.

Code defining the common currency used by the terminal in case the Transaction Currency Code is different from the Application Currency Code Factor used in the conversion from the Transaction Currency Code to the Transaction Reference Currency Code

Terminal

n3

-

‘9F3C’

2

Terminal

n8

--

4

Indicates the implied position of the decimal point from the right of the transaction amount, with the Transaction Reference Currency Code represented according to ISO 4217 Counter maintained by the terminal that is incremented by one for each transaction

Terminal

n1

-

‘9F3D’

1

Terminal

n 4-8

-

‘9F41’

2-4

Indicates the functions performed in a transaction

Terminal

b

-

‘9B’

2

Local time that the transaction was authorised

Terminal

n6 HHMMSS

-

‘9F21’

3

80


Name Transaction Type Unpredictable Number Upper Consecutive Offline Limit

Description Indicates the type of financial transaction, represented by the first two digits of ISO 8583:1987 Processing Code Value to provide variability and uniqueness to the generation of a cryptogram Issuer-specified preference for the maximum number of consecutive offline transactions for this ICC application allowed in a terminal without online capability

December, 2000

Source Terminal

Format n2

Template -

Tag ‘9C’

Length 1

Terminal

b

-

‘9F37’

4

ICC

b

‘70’ or ‘77’

‘9F23’

1

Table A - 1 - Data Elements Dictionary When the length defined for the data object is greater than the length of the actual data, the following rules apply: • A data element in format n is right justified and padded with leading hexadecimal zeroes • A data element in format cn is left justified and padded with trailing hexadecimal ‘F’s • A data element in format an is left justified and padded with trailing hexadecimal zeroes • A data element in format ans is left justified and padded with trailing hexadecimal zeroes When data is moved from one entity to another (for example, card to terminal), it shall always be passed in order from high order to low order, regardless of how it is internally stored. The same rule applies when concatenating data. Note: Data that can occur in template ‘70’ or ‘77’ can never occur in both.

December, 2000


81

The tags allocated to the data elements are according to Table A-2: Name Application Identifier (AID) Application Label Track 2 Equivalent Data Application Primary Account Number (PAN) Cardholder Name Application Expiration Date Application Effective Date Issuer Country Code Transaction Currency Code Language Preference Service Code Application Primary Account Number (PAN) Sequence Number Transaction Currency Exponent Application Template File Control Information (FCI) Template Application Elementary File (AEF) Data Template Issuer Script Template 1 Issuer Script Template 2 Directory Discretionary Template Response Message Template Format 2 Response Message Template Format 1 Amount, Authorised (Binary) Application Interchange Profile Command Template Dedicated File (DF) Name Issuer Script Command Application Priority Indicator Short File Identifier (SFI) Authorisation Code Authorisation Response Code Card Risk Management Data Object List 1 (CDOL1) Card Risk Management Data Object List 2 (CDOL2) Cardholder Verification Method (CVM) List Certification Authority Public Key Index Issuer Public Key Certificate Issuer Authentication Data Issuer Public Key Remainder Signed Static Application Data Application File Locator (AFL) Terminal Verification Results Transaction Certificate Data Object List (TDOL) Transaction Certificate (TC) Hash Value Transaction Personal Identification Number (PIN) Data Transaction Date Transaction Status Information Transaction Type

Template ‘61’ ‘61’ or ‘A5’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ − ‘A5’ ‘70’ or ‘77’ ‘70’ or ‘77’

Tag ‘4F’ ‘50’ ‘57’ ‘5A’ ‘5F20’ ‘5F24’ ‘5F25’ ‘5F28’ ‘5F2A’ ‘5F2D’ ‘5F30’ ‘5F34’

− ‘70’ or ‘77’ − − − − ‘61’ − − − ‘77’ or ‘80’ − ‘6F’ ‘71’ or ‘72’ ‘61’ or ‘A5’ ‘A5’ − − ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ − ‘70’ or ‘77’ ‘70’ or ‘77’ ‘77’ or ‘80’ − ‘70’ or ‘77’ − − − − −

‘5F36’ ‘61’ ‘6F’ ‘70’ ‘71’ ‘72’ ‘73’ ‘77’ ‘80’ ‘81’ ‘82’ ‘83’ ‘84’ ‘86’ ‘87’ ‘88’ ‘89’ ‘8A’ ‘8C’ ‘8D’ ‘8E’ ‘8F’ ‘90’ ‘91’ ‘92’ ‘93’ ‘94’ ‘95’ ‘97’ ‘98’ ‘99’ ‘9A’ ‘9B’ ‘9C’

82

Annex A - Data Elements Table Name Directory Definition File (DDF) Name Acquirer Identifier Amount, Authorised (Numeric) Amount, Other (Numeric) Amount, Other (Binary) Application Discretionary Data Application Identifier (AID) Application Usage Control Application Version Number Application Version Number Cardholder Name -Extended Issuer Action Code - Default Issuer Action Code - Denial Issuer Action Code - Online Issuer Application Data Issuer Code Table Index Application Preferred Name Last Online Application Transaction Counter (ATC) Register Lower Consecutive Offline Limit Merchant Category Code Merchant Identifier Personal Identification Number (PIN) Try Counter Issuer Script Identifier Issuer URL Terminal Country Code Terminal Floor Limit Terminal Identification Terminal Risk Management Data Interface Device (IFD) Serial Number Track 1 Discretionary Data Track 2 Discretionary Data Transaction Time Certification Authority Public Key Index Upper Consecutive Offline Limit Application Cryptogram Cryptogram Information Data ICC PIN Encipherment Public Key Certificate ICC PIN Encipherment Public Key Exponent ICC PIN Encipherment Public Key Remainder Issuer Public Key Exponent Terminal Capabilities Cardholder Verification Method (CVM) Results Terminal Type Application Transaction Counter (ATC) Unpredictable Number Processing Options Data Object List (PDOL) Point-of-Service (POS) Entry Mode Amount, Reference Currency

December, 2000 Template ‘61’ − − − − ‘70’ or ‘77’ − ‘70’ or ‘77’ ‘70’ or ‘77’ − ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘77’ or ‘80’ ‘A5’ ‘61’ or ‘A5’ −

Tag ‘9D’ ‘9F01’ ‘9F02’ ‘9F03’ ‘9F04’ ‘9F05’ ‘9F06’ ‘9F07’ ‘9F08’ ‘9F09’ ‘9F0B’ ‘9F0D’ ‘9F0E’ ‘9F0F’ ‘9F10’ ‘9F11’ ‘9F12’ ‘9F13’

‘70’ or ‘77’ − − − ‘71’ or ‘72’ ‘A5’ − − − − − ‘70’ or ‘77’ ‘70’ or ‘77’ − − ‘70’ or ‘77’ ‘77’ or ‘80’ ‘77’ or ‘80’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ − − − ‘77’ or ‘80’ − ‘A5’ − −

‘9F14’ ‘9F15’ ‘9F16’ ‘9F17’ ‘9F18’ ‘5F50’ ‘9F1A’ ‘9F1B’ ‘9F1C’ ‘9F1D’ ‘9F1E’ ‘9F1F’ ‘9F20’ ‘9F21’ ‘9F22’ ‘9F23’ ‘9F26’ ‘9F27’ ‘9F2D’ ‘9F2E’ ‘9F2F’ ‘9F32’ ‘9F33’ ‘9F34’ ‘9F35’ ‘9F36’ ‘9F37’ ‘9F38’ ‘9F39’ ‘9F3A’

December, 2000


Name Application Reference Currency Transaction Reference Currency Transaction Reference Currency Exponent Additional Terminal Capabilities Transaction Sequence Counter Application Currency Code Application Reference Currency Exponent Application Currency Exponent Data Authentication Code ICC Public Key Certificate ICC Public Key Exponent ICC Public Key Remainder Dynamic Data Object List (DDOL) Static Data Authentication Tag List Signed Dynamic Application Data ICC Dynamic Number File Control Information (FCI) Proprietary Template File Control Information (FCI) Issuer Discretionary Data

Template ‘70’ or ‘77’ − − − − ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘70’ or ‘77’ ‘6F’ ‘A5’

Table A - 2 - Data Elements Tags

83 Tag ‘9F3B’ ‘9F3C’ ‘9F3D’ ‘9F40’ ‘9F41’ ‘9F42’ ‘9F43’ ‘9F44’ ‘9F45’ ‘9F46’ ‘9F47’ ‘9F48’ ‘9F49’ ‘9F4A’ ‘9F4B’ ‘9F4C’ ‘A5’ ‘BF0C’

84



December, 2000

December, 2000

Annex B – Rules for BER-TLV Data Objects

85


B.1 Coding of BER-TLV Data Objects As defined in ISO/IEC 8825, a BER-TLV data object consists of 2-3 consecutive fields: • The tag field (T) consists of one or more consecutive bytes. It codes a class, a type,

and a number (see Table C-1). The tag field of the data objects described in this specification is coded on one or two bytes. • The length field (L) consists of one or more consecutive bytes. It codes the length

of the following field. The length field of the data objects described in this specification is coded on one, two, or three bytes. • The value field (V) codes the value of the data object. If L = ‘00’, the value field is

not present. A BER-TLV data object belongs to one of the following two categories: • A primitive data object where the value field contains a data element for financial

transaction interchange. • A constructed data object where the value field contains one or more primitive or

constructed data objects. The value field of a constructed data object is called a template. The coding of BER-TLV data objects is defined for as follows.

B1.1 Coding of the Tag Field of BER-TLV Data Objects The first byte of the tag field of a BER-TLV data object is according to Table C-1: b8 0 0 1 1

b7 0 1 0 1

b6

b5

b4

b3

b2

b1

0 1 1

1 1 1 Any other value

1

Meaning Universal class Application class Context-specific class Private class Primitive data object Constructed data object See subsequent bytes Tag number

Table B - 1 - Tag Field Structure (First Byte) BER-TLV

86


December, 2000

According to ISO/IEC 8825, Table C-2 defines the coding rules of the subsequent bytes of a BER-TLV tag when tag numbers ≥ 31 are used (that is, bits b5 - b1 of the first byte equal ‘11111’). b8 1 0

b7

b6

b5

b4

b3

b2

Any value > 0

b1

Meaning Another byte follows Last tag byte (Part of) tag number

Table B - 2 - Tag Field Structure (Subsequent Bytes) BER-TLV Before, between or after TLV-coded data objects, ‘00’ or ‘FF’ bytes without any meaning may occur (e.g. due to erased or modified TLV-coded data objects). The coding of the tag field of a BER-TLV data object is according to the following rules: • The following application class templates defined in ISO/IEC 7816 apply: ‘61’ and ‘6F.’ • The following range of application class templates is defined in Part I: ‘70’ to ‘7F’. The meaning is then specific to the context of an application according to this specification. Tags ‘78’, ‘79’, ‘7D’, and ‘7E’ are defined in ISO/IEC 7816-6 and are not used in this specification. • The application class data objects defined in ISO/IEC 7816 and described in Part I are used according to the ISO/IEC 7816 definition. • Context-specific class data objects are defined in the context of this specification or in the context of the template in which they appear. • The coding of primitive context-specific class data objects in the ranges ‘80’ to ‘9E’ and ‘9F00’ to ‘9F4F’ is reserved for this specification. • The coding of primitive context-specific class data objects in the range ‘9F50’ to ‘9F7F’ is reserved for the payment systems. • The coding of primitive and constructed private class data objects is left to the discretion of the issuer.

B1.2 Coding of the Length Field of BER-TLV Data Objects The coding of the length field is as follows. When bit b8 of the most significant byte of the length field is set to 0, the length field consists of only one byte. Bits b7 to b1 code the number of bytes of the value field. The length field is within the range 1 to 127.

December, 2000


87

When bit b8 of the most significant byte of the length field is set to 1, the subsequent bits b7 to b1 of the most significant byte code the number of subsequent bytes in the length field. The subsequent bytes code an integer representing the number of bytes in the value field. Two bytes are necessary to express up to 255 bytes in the value field.

B1.3 Coding of the Value Field of Data Objects A data element is the value field (V) of a primitive BER-TLV data object. A data element is the smallest data field that receives an identifier (a tag). A primitive data object is structured according to Table B-3: Tag (T)

Length (L)

Value (V)

Table B - 3 - Primitive BER-TLV Data Object (Data Element) A constructed BER-TLV data object consists of a tag, a length, and a value field composed of one or more BER-TLV data objects. A record in an AEF governed by this specification is a constructed BER-TLV data object. A constructed data object is structured according to Table B-4: Tag (T)

Length (L)

Primitive or constructed BER-TLV data object number 1

...

Primitive or constructed BER-TLV data object number n

Table B - 4 - Constructed BER-TLV Data Object

88



December, 2000

December, 2000

Annex C – Coding of Data Elements

Annex C - Coding of Data Elements used in the Transaction Processing This annex provides the coding for specific data elements used to control the transaction flow in the terminal or to record the status of processing for the transaction. In the tables, a ‘1’ means that if that bit has the value ‘1’, the corresponding ‘Meaning’ applies. An ‘x’ means that the bit does not apply. Data (bytes or bits) indicated as RFU shall be set to ‘0’.

89

90


December, 2000

Annex C.1 - Application Interchange Profile Byte 1 (Leftmost): b8 0 x x

b7 x 1 x

b6 x x 1

b5 x x x

b4 x x x

b3 x x x

b2 x x x

b1 x x x

x x x x x

x x x x x

x x x x x

1 x x x x

x 1 x x x

x x 1 x x

x x x 1 x

x x x x 0

b2 x x x x x x 0 x

b1 x x x x x x x 0

Meaning RFU Offline static data authentication is supported Offline dynamic data authentication is supported Cardholder verification is supported Terminal risk management is to be performed Issuer authentication is supported14 Combined DDA – GENERATE AC supported RFU

Byte 2 (Rightmost): b8 0 x x x x x x x

b7 x 0 x x x x x x

b6 x x 0 x x x x x

b5 x x x 0 x x x x

b4 x x x x 0 x x x

b3 x x x x x 0 x x

Meaning RFU RFU RFU RFU RFU RFU RFU RFU

Table C - 1 - Application Interchange Profile

When this bit is set to ‘1’, Issuer Authentication using the EXTERNAL AUTHENTICATE command, is supported 14

December, 2000


Annex C.2 - Application Usage Control Byte 1 (Leftmost): b8 1 x x x x x x x

b7 x 1 x x x x x x

b6 x x 1 x x x x x

b5 x x x 1 x x x x

b4 x x x x 1 x x x

B3 x x x x x 1 x x

b2 x x x x x x 1 x

b1 x x x x x x x 1

Meaning Valid for domestic cash transactions Valid for international cash transactions Valid for domestic goods Valid for international goods Valid for domestic services Valid for international services Valid at ATMs Valid at terminals other than ATMs

b2 x x x x x x 0 x

b1 x x x x x x x 0

Meaning Domestic cashback allowed International cashback allowed RFU RFU RFU RFU RFU RFU


b7 x 1 x x x x x x

b6 x x 0 x x x x x

b5 x x x 0 x x x x

b4 x x x x 0 x x x

b3 x x x x x 0 x x

Table C - 2 - Application Usage Control

91

92


December, 2000

Annex C.3 - Cardholder Verification Rule Format Byte 1 (Leftmost): Cardholder Verification Method (CVM) Codes b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0

RFU 0

Fail cardholder verification if this CVM is unsuccessful

1

Apply succeeding CVR if this CVM is unsuccessful 0

0

0

0

0

0

Fail CVM processing

0

0

0

0

0

1

Plaintext PIN verification performed by ICC

0

0

0

0

1

0

Enciphered PIN verified online

0

0

0

0

1

1

Plaintext PIN verification performed by ICC and signature (paper)

0

0

0

1

0

0

Enciphered PIN verification performed by ICC

0

0

0

1

0

1

Enciphered PIN verification performed by ICC and signature (paper)

0

x

x

x

x

x

Values in the range 000110-011101 reserved for future use by this specification

0

1

1

1

1

0

Signature (paper)

0

1

1

1

1

1

No CVM required

1

0

x

x

x

x

Values in the range 100000-101111 reserved for use by the individual payment systems

1

1

x

x

x

x

Values in the range 110000-111110 reserved for use by the issuer

1

1

1

1

1

1

This value is not available for use

Table C - 3 - CVM Codes

December, 2000


Value ‘00’ ‘01’ ‘02’ ‘03’ ‘04’ - ‘05’ ‘06’

93

Meaning

‘07’ ‘08’ ‘09’ ‘0A’ - ‘7F’ ‘80’ - ‘FF’

Always If cash or cashback If not cash or cashback If terminal supports the CVM15 RFU If transaction is in the application currency16 and is under X value If transaction is in the application currency and is over X value If transaction is in the application currency and is under Y value If transaction is in the application currency and is over Y value RFU Reserved for use by individual payment systems

Table C - 4 - CVM Condition Codes

In the case of offline PIN CVM, this means ‘If offline PIN pad present’. In the case of online PIN CVM, this means ‘If online PIN pad present’. 16 That is, Transaction Currency Code = Application Currency Code. 15

94


Annex C.4 - Issuer Code Table Index

Value ‘01’ ‘02’ ‘03’ ‘04’ ‘05’ ‘06’ ‘07’ ‘08’ ‘09’ ‘10’

Refers to Part 1 of ISO 8859 Part 2 of ISO 8859 Part 3 of ISO 8859 Part 4 of ISO 8859 Part 5 of ISO 8859 Part 6 of ISO 8859 Part 7 of ISO 8859 Part 8 of ISO 8859 Part 9 of ISO 8859 Part 10 of ISO 8859

Table C - 5 - Issuer Code Table Index

December, 2000

December, 2000


95

Annex C.5 - Terminal Verification Results Byte 1: (Leftmost) b8 1 x x x x x x x x

b7 x 1 x x x x x x x

b6 x x 1 x x x x x x

b5 x x x 1 x x x x x

b4 x x x x 1 x x x x

b3 x x x x x 1 0 x x

b2 x x x x x x x 0 x

b1 x x x x x x x x 0

Meaning Offline data authentication was not performed Offline static data authentication failed ICC data missing Card appears on terminal exception file17 Offline dynamic data authentication failed Combined DDA/AC Generation failed RFU RFU RFU

Meaning ICC and terminal have different application versions Expired application Application not yet effective Requested service not allowed for card product New card RFU RFU RFU

Byte 2: b8 1

b7 x

b6 x

b5 x

b4 x

b3 x

b2 x

b1 x

x x x x x x x

1 x x x x x x

x 1 x x x x x

x x 1 x x x x

x x x 1 x x x

x x x x 0 x x

x x x x x 0 x

x x x x x x 0

There is no requirement in this specification for an exception file, but it is recognised that some terminals may have this capability. 17

96


December, 2000

Byte 3: b8 1 x x x

b7 x 1 x x

b6 x x 1 x

b5 x x x 1

b4 x x x x

b3 x x x x

b2 x x x x

b1 x x x x

x

x

x

x

1

x

x

x

x x x

x x x

x x x

x x x

x x x

1 x x

x 0 x

x x 0

Meaning Cardholder verification was not successful Unrecognised CVM PIN Try Limit exceeded PIN entry required and PIN pad not present or not working PIN entry required, PIN pad present, but PIN was not entered Online PIN entered RFU RFU

Byte 4: b8 1 x x x

b7 x 1 x x

b6 x x 1 x

b5 x x x 1

b4 x x x x

b3 x x x x

b2 x x x x

b1 x x x x

x x x x

x x x x

x x x x

x x x x

1 x x x

x 0 x x

x x 0 x

x x x 0

Meaning Transaction exceeds floor limit Lower consecutive offline limit exceeded Upper consecutive offline limit exceeded Transaction selected randomly for online processing Merchant forced transaction online RFU RFU RFU

December, 2000


97

Byte 5 (Rightmost): b8 1 x x

b7 x 1 x

b6 x x 1

b5 x x x

b4 x x x

b3 x x x

b2 x x x

b1 x x x

x

x

x

1

x

x

x

x

x x x x

x x x x

x x x x

x x x x

0 x x x

x 0 x x

x x 0 x

x x x 0

Meaning Default TDOL used Issuer authentication was unsuccessful Script processing failed before final GENERATE AC Script processing failed after final GENERATE AC RFU RFU RFU RFU

Table C - 6 - Terminal Verification Results

98


December, 2000

Annex C.6 - Transaction Status Information Byte 1 (Leftmost): b8 1 x x x x x x x

b7 x 1 x x x x x x

b6 x x 1 x x x x x

b5 x x x 1 x x x x

b4 x x x x 1 x x x

b3 x x x x x 1 x x

b2 x x x x x x 0 x

b1 x x x x x x x 0

Meaning Offline data authentication was performed Cardholder verification was performed Card risk management was performed Issuer authentication was performed Terminal risk management was performed Script processing was performed RFU RFU

b2 x x x x x x 0 x

b1 x x x x x x x 0

RFU RFU RFU RFU RFU RFU RFU RFU


b7 x 0 x x x x x x

b6 x x 0 x x x x x

b5 x x x 0 x x x x

b4 x x x x 0 x x x

b3 x x x x x 0 x x

Meaning

Table C - 7 - Transaction Status Information

December, 2000 Annex D – Transaction Processing for Chip E-Commerce

Annex D

99

Transaction Processing for Chip Electronic Commerce

This section defines a transaction flow that begins with the Cardholder System checking for the presence of an IC Card while conducting a purchase, continues with the transmission of the purchase and authorisation requests, and ends with the transmission of the capture message from the Merchant Server or Payment Gateway. The Payment Gateway is responsible for reformatting the SET message (along with additional IC Card related data) and transmitting an authorisation request to the issuer. The manner in which the Payment Gateway reformats, transmits and receives messages to and from the issuer is dependent on Payment Systems requirements. These requirements are outside the scope of this document. The Transaction Processing for Chip Electronic Commerce defines the use of an integrated chip card (IC Card) application to conduct a credit or debit transaction in an electronic commerce environment using SET 1.0 compliant software. It leverages the EMV functions described in section 6 with the Secure Electronic Transaction™ (SET) Specification (a secure protocol for which credit and debit products may be used to conduct electronic commerce), to provide the foundation for secure, portable, cost–effective, IC Card based transactions over the Internet In addition, the Transaction Processing for Chip Electronic Commerce takes advantage of two enhancements to the SET protocol: •

SET Common Chip Extension:

Extends the SET protocol to support the transport of IC Card related data.

•

Online PIN extension

Extends the SET protocol to support the online transport of a cardholders’ PIN.

SET provides an electronic commerce infrastructure that delivers: •

Confidentiality of information

•

Integrity of data

•

Interoperability

•

Certificate based authentication

100

Annex D –Transaction Processing for Chip E-Commerce December, 2000

The Transaction Processing for Chip Electronic Commerce extends the SET Specification by supporting two key features native to EMV IC Card applications: •

Online card authentication, through the use of a cryptogram

•

Cardholder verification, through the use of an optional Cardholder PIN

The Chip Electronic Commerce payment system consists of eight components:

Payment System Issuer

Acquirer

Internet and SET software

SET Payment Gateway

IC Card Cardholder

IC Card Interface Device

Internet Access Device

SET Merchant Server

Cardholder System

Figure II- 7 - Chip Electronic Commerce System

1. Issuer 2. Cardholder 3. EMV IC Card

4. Cardholder System

5. Merchant Server

6. Payment Gateway

7. Acquirer

8. Payment System

A financial institution that issues payment card products to individuals; An authorised holder of a payment card issued by an issuer. Stores the cardholder’s payment data and is capable of generating a cryptogram to authenticate the card and optionally verify a cardholder’s PIN. Serves as the interface between the EMV IC Card and the SET merchant server. It is responsible for authenticating the merchant to the cardholder. A system that interacts with the Cardholder System for electronic payments. The Merchant Server also interacts with the acquirer using the payment protocol to receive authorisation and capture services for electronic payment transactions A system that interacts with the Merchant Server and an acquirer’s legacy system to support the authorisation and capture of SET transactions. A financial institution that supports merchants by providing a service for processing payment card transactions; A franchiser of payment system networks and branded instruments.


101

The Chip Electronic Commerce Specification contains the following parts: Section D.1

System Architecture: Defines the additional requirements placed upon the components of the Chip Electronic Commerce system by this specification

Section D.2

Transaction Processing: defines the manner in which a purchase is processed in the Chip Electronic Commerce system

Annex E to G

Provides supplementary information.

D.1 System Architecture The transaction processing capabilities of each component in the Chip Electronic Commerce system are defined in the following sections: D.1.1

EMV Debit/Credit Applications

Describes the attributes of EMV debit or credit card applications that participate in EMV Chip Electronic Commerce transactions.

D.1.2

Cardholder System

Describes the pre–conditions the Cardholder System shall meet prior to transaction processing.

D.1.3

Merchant Server

Describes the pre–conditions that Merchant Servers shall meet prior to transaction processing.

D.1.4

Payment Gateway

Describes the pre–conditions that Payment Gateways shall meet prior to transaction processing.

102


D.1.1 EMV Debit/Credit Applications The EMV Debit/Credit applications are IC Card applications that are capable of generating for each transaction an application cryptogram that can decline or approve off–line, or else, request the on–line referral or authorisation of a transaction. The Transaction Processing for Chip Electronic Commerce does not require any modification to EMV–compliant IC Cards. During application selection, an issuer may supplement the EMV defined branding mechanisms, i.e. the display of an Application Label or Preferred Name, by showing its cardholder a visual image of its brand. More information is provided in Annex E Issuer URL for Electronic Commerce. To do this, an issuer should store an additional data element, the Issuer URL, in the File Control Information of its Application Definition File. If used, the format, template, tag, and length to be applied to this data element are as follows: Name Issuer URL

Format ans

Template ‘BF0C’

Tag ‘5F50’

Length var.

Table D - 1 - Issuer URL in FCI description

Tag ‘6F’

Value FCI Template ‘84’ DF Name ‘A5’ FCI Proprietary Template ‘50’ Application Label ‘87’ Application Priority Indicator ‘9F38’ PDOL ‘5F2D’ Language Preference ‘9F11’ Issuer Code Table Index ‘9F12’ Application Preferred Name ‘BF0C’ FCI Issuer Discretionary Data ‘5F50’ Issuer URL

Table D - 2 - Location of Issuer URL in FCI Template

Presence M M M O O O O O O O O


103

D.1.2 Cardholder System The Cardholder System is the combination of hardware and software required interacting with the cardholder, the cardholder’s IC Card, and a SET Merchant Server in order to participate in the Transaction Processing for Chip Electronic Commerce. This section describes the additional requirements imposed upon the Cardholder System by this specification. Since there are many possible ways in which a Cardholder System can be configured, this description treats the component as if it were a black box. Appendix F offers a high level model describing the Cardholder System. The physical requirements that the EMV capable Interface Device (IFD) must meet are prescribed by Book 1. The physical characteristics that the Cardholder System and the PIN entry device must possess to process a cardholder’s PIN are defined by individual Payment System rules. The Cardholder System must be aware of its PIN processing and interface device capabilities. This section includes the following: D.1.2.1

Cardholder System Functions

Describes the functions through which Cardholder Systems interact with IC Cards

D.1.2.2

Commands

Lists the commands that Cardholder Systems shall support.

D.1.2.3

Data Elements

Defines the coding and/or values to be ascribed to data elements that Cardholder Systems shall store or create.

D.1.2.4

SET message extensions

Lists the SET message extensions that Cardholder Systems shall support.

D.1.2.1

Cardholder System Functions

Section D.1.2.1 describes the functions performed by the Cardholder System on behalf of the IC Card. The Cardholder System shall perform the following functions, which are detailed in Section D.2, Transaction Processing:

104


D.2.2.1 Card Selection D.2.2.2 Application Selection D.2.2.3 Application Initiation D.2.2.4 Read Application Data D.2.2.5 Cardholder Verification D.2.2.6 Terminal Action Analysis D.2.2.7 Issuer Script Processing & Completion Due to the special nature of the electronic commerce environment, the following EMV defined functions are not executed: 6.3

Offline Data Authentication

6.4

Processing Restrictions

6.6

Terminal Risk Management

D.1.2.2

Commands

The Cardholder System communicates with the IC Card application by issuing commands and interpreting the card’s response. Part II of Book 1 and Part I of this book prescribe the coding conventions and structuring of command and response APDUs. The Cardholder System shall support the following commands: •

SELECT

Selects an application definition file, directory definition file or Payment System Environment.

•

GET PROCESSING OPTIONS

Initiates the transaction within the IC Card.

•

READ RECORD

Retrieves the data in the records of linear files.

•

GET DATA

Retrieves a data object not encapsulated in a record within the current application.

•

VERIFY

Initiates in the IC Card the comparison of the Transaction PIN Data sent in the data field of the command with the reference PIN data associated with the application.

•

GENERATE AC

Initiates the generation of an application cryptogram by the IC Card.

•

EXTERNAL AUTHENTICATE

Initiates the verification of the Issuer Authentication Data generated by the issuer.


105

The Cardholder System shall be able to decode all responses generated by cards, which respond to commands as prescribed by Part I of this book.

D.1.2.3

Data Elements

This section defines the Data Elements resident at the Cardholder System and their values. For more information regarding other EMV related Data Elements and their sources, see Table D-9. Resident Data Elements The Cardholder System shall store values for the following Resident Data Elements: • Amount Other • BrandID—AID Mappings • ISO 8859 Code Table • Terminal Type • Transaction Type • Terminal Verification Results Amount Other Amount Other encodes a cashback amount. Since there is no cashback in the purchase transaction, the Data Element shall be defined as: Data Element Amount Other

EMV tag ‘9F04’ –or– ‘9F03’

Format b –or– n12

Length 4

Value 0000

6

000000000000

BrandID—AID Table The BrandID—AID Table contains a mapping from each SET brandID to its corresponding Application Identifiers (AIDs). The Cardholder System should have a mechanism to update its BrandID-AID Table. The Cardholder System’s BrandID—AID table shall include the AIDs defined in the Payment System Specifications.

ISO 8859 code table The ISO 8859 Code Table enables the Cardholder System to decode card resident data objects such as Application Preferred Name. For more information about coding this table, see book 4.

106


Terminal Type The Terminal Type specifies the terminal’s environment, its communications capabilities and its operational control. To indicate that it is an “unattended, online, controlled by cardholder” device, the Data Element shall be defined as: Data Element Terminal Type

EMV tag ‘9F35’

Format n2

Length 1

Value 34

Transaction Type The Transaction Type specifies the type of financial transactions the Cardholder System performs. To indicate that the transaction is a purchase of goods or service, the Data Element shall be defined as: Data Element Transaction Type

EMV tag ‘9C’

Format n2

Length 1

Value 00

Terminal Verification Results The Terminal Verification Results is a record of the outcome of the various application functions performed by the Cardholder System. It shall be defined as: Data Element Terminal Verification Results

EMV tag ‘95’

Format b

Length 5

Value static and dynamic

The values to be ascribed to bits that are static are indicated below. Bits whose values are to be dynamically set, will be set by the Cardholder System during the course of the transaction, as prescribed later in this specification. The coding of this Data Element is as follows: Byte Bit Meaning 1 8 Offline data authentication was not performed

Value 1

7

Offline static data authentication failed

0

6

IC Card Data missing

Dynamic

5

Card appears on terminal exception file

0

4

Offline dynamic data authentication failed

0

3

RFU

0

2

RFU

0

1

RFU

0

December, 2000 Annex D – Transaction Processing for Chip E-Commerce Byte Bit Meaning 2 8 IC Card and terminal have different application versions

Value 0

7

Expired application

0

6

Application not yet effective

0

5

Requested service not allowed for card product

0

4

New Card

0

3

RFU

0

2

RFU

0

1

RFU

0

Byte Bit Meaning 3 8 Cardholder verification was not successful

Value Dynamic

7

Unrecognized CVM

Dynamic

6

PIN Try Limit exceeded

Dynamic

5

PIN entry required and PIN pad not present or not Dynamic working

4

PIN entry required, PIN pad present but PIN was Dynamic not entered

3

Online PIN entered

Dynamic

2

RFU

0

1

RFU

0

Byt Bit Meaning e 4 8 Transaction exceeds floor limit

Value 1

7

Lower consecutive offline limit exceeded

0

6

Upper consecutive offline limit exceeded

0

5

Transaction selected randomly for online processing

0

4

Merchant forced transaction online

0

3

RFU

0

2

RFU

0

1

RFU

0

107

108


Byte Bit Meaning 5 8 Default TDOL used

D.1.2.4

Value 0

7

Issuer authentication was unsuccessful

Dynamic

6

Script processing failed before final GENERATE AC

Dynamic

5

Script processing failed after final GENERATE AC Dynamic

4

RFU

0

3

RFU

0

2

RFU

0

1

RFU

0

SET Message Extensions

This section describes the SET Message Extensions that the Cardholder System shall support in order to conduct an EMV transaction. The Cardholder System must be able to support the following message extensions as prescribed by the SET Common Chip Extension and SET Online PIN Extension. • commonChip Created by the Cardholder System and placed in the PReq message; this extension carries the cryptogram and related data required by the acquirer to format a Payment System’s authorisation request. •

acqCardExtensions

Created by the Payment Gateway and placed within the AcqCardMsgData field of the PRes message; this extension carries Issuer Authentication and Issuer Script data.

•

onlinePIN

Created by the Cardholder System and placed in the PReq message; this extension identifies the presence in the RSA/OAEP block of PIN data entered by the cardholder.

D.1.3 Merchant Server The Merchant Server is the component that interacts with the Cardholder System in support of electronic payments. The Merchant Server also interacts with the acquirer’s Payment Gateway. The Transaction Processing for Chip Electronic Commerce does not require any modification to Merchant Servers.


109

D.1.4 Payment Gateway The Payment Gateway is the system that interacts with the Merchant Server and an acquirer’s legacy system to support the authorisation and capture of SET transactions. This section defines the additional requirements imposed upon the Payment Gateway by this specification. The Payment Gateway must be able to process the following message extensions as prescribed by the SET Common Chip Extension. •

commonChip

Created by the Cardholder System and placed in the PReq message; this extension carries the cryptogram and related data required by the acquirer to format a Payment System’s authorisation request.

•

acqCardExtensions

Created by the Payment Gateway and placed within the AcqCardMsgData field of the PRes message; this extension carries Issuer Authentication and Issuer Script data back to the Cardholder System.

The Payment Gateway shall be able to process the following message extensions as prescribed by the SET Online PIN Extension. •

onlinePIN

Created by the Cardholder System and placed in the PReq message; this extension identifies the presence in the RSA/OAEP block of PIN data entered by the cardholder.

The SETExtension component of the Payment Gateway’s certificate shall indicate that the Payment Gateway supports the commonChip extension. The SETExtension component of the Payment Gateway’s certificate shall indicate that the Payment Gateway supports the onlinePIN extension.

110

Annex D - Transaction Processing for Chip E-Commerce December, 2000

D.2 Transaction Processing This section defines the manner in which purchase transactions are processed in the EMV Chip Electronic Commerce system. It describes all EMV functions and SET messages related to the authorisation and capture of a payment. Organisation The Transaction Processing includes the following: D.2.1 Transaction Flow: provides an overview of the interactions required completing a purchase. D.2.2

IC Card to Cardholder System Interface: describes the functions between the IC Card application and the Cardholder System.

D.2.3

Cardholder System to Merchant Server Interface: describes the interactions between the Cardholder System and the Merchant Server.

D.2.4

Merchant Server to Payment Gateway Interface: describes the interaction between the Merchant Server and the Payment Gateway. Section D.2.1 provides a high–level overview of the transaction processing phases. The remaining chapters describe the processing of each phase in detail.

D.2.1 Purchase Transaction Flow This Section provides a high–level overview of the purchase transaction. It provides an illustration of the transaction flow as well as a summary description of each phase: D.2.1.1

Diagram of Transaction Flow: Illustrates the transaction flow.

D.2.1.2

Explanation of Transaction Flow; Provides a brief description of the transaction flow.

D.2.1.1

Diagram of Transaction Flow

This section illustrates the EMV functions and SET messages processed to conduct a purchase transaction.


111

SET initiation message

Card Selection

Application Selection

Application Initiation

Read Application

Purchase Initialization Request

Purchase Initialization Response



Purchase Request

Authorization Request

Purchase response

Authorization response

Issuer Script Processing and Completion Capture Request

Capture Response

Figure II- 8 - Diagram of Chip Electronic Commerce transaction flow

D.2.1.2

Explanation of Transaction Flow

This section describes the phases of the purchase transaction in the order in which they occur. SET Payment Initiation The Merchant Server invokes the Cardholder System and informs it of the payment brands it accepts.

112


Card Selection The cardholder presents to the Cardholder System the payment card to be used for the purchase. Application Selection The Cardholder System selects an application from the card, with input from the cardholder if necessary. Application Initiation The Cardholder System initiates the card application to determine whether it and the card agree about how the transaction should be processed. Read Application The Cardholder System reads the application data. Purchase Initialization Request The Cardholder System initialises the purchase by informing the Merchant Server how the cardholder intends to pay. Purchase Initialization Response The Merchant Server returns the information necessary to complete the purchase. Cardholder Verification The Cardholder System retrieves information from the cardholder that may verify their identity and either presents it to the card or transmits to the issuer for verification Terminal Action Analysis The Cardholder System requests an online authorisation of the transaction. The card determines whether to decline the transaction off–line or to request an online authorisation or referral. Purchase Request The Cardholder System requests a purchase and provides the Merchant Server with the data that it, the Payment Gateway and the issuer need to respond to the request. Authorisation Request The Merchant Server sends the Payment Gateway the information that it needs to verify the authenticity of the cardholder and to create a Payment System’s authorisation request message. Note: SET allows a merchant to return a PRes message to the Cardholder System before authorisation processing. Authorisation Response The Payment Gateway sends the Merchant Server a message that indicates whether the transaction has been authorised or declined by the issuer.


113

Purchase Response The Merchant Server informs the Cardholder System of the status of the transaction sometime after it has received the Cardholder System’s Purchase Request. Issuer Script Processing and Completion The Cardholder System ends the involvement of the cardholder and IC Card. Capture Request The Merchant Server may request that the Payment Gateway capture the transaction after it has received the Payment Gateway’s Authorisation Response. Capture Response The Payment Gateway notifies that Merchant Server of the status of its request for capture.

D.2.2 IC Card—Cardholder System Functions This section defines the transaction processing phases that involve interaction between the IC Card application and the Cardholder System. Phases that do not involve interaction between the card and the Cardholder System are detailed in following Sections: D.2.2.1

Card Selection: Describes how the Cardholder indicates which payment card to use for the purchase.

D.2.2.2

Application Selection: Describes how the Cardholder System, with input from the cardholder, selects a card application to participate in the transaction.

D.2.2.3

Application Initiation: Describes how the Cardholder System initiates the card application.

D.2.2.4

Read Application Data: Describes how the Cardholder System reads the card application’s records.

D.2.2.5

Cardholder Verification: Describes how the Cardholder System verifies the identity of the cardholder.

D.2.2.6

Terminal Action Analysis: Describes how the IC Card application generates an Application Cryptogram.

D.2.2.7

Issuer Script Processing and Completion: Describes how the Cardholder System ends its involvement with the processing of the transaction.

114


D.2.2.1

Card Selection

Purpose Card selection is the phase of transaction processing in which the cardholder indicates which payment card should be used for the purchase. This phase supplements the SET defined account selection process. Conditions of execution The Cardholder System shall always perform Card Selection. Process description The Cardholder System shall integrate the execution of Card Selection with the execution of account selection. In doing so, the following requirements shall be met: • All brands accepted by the Merchant Server shall be displayed. •

The Cardholder shall be offered all available payment options.

•

Once a chip card has been selected, the Cardholder System shall request that the Cardholder not remove the card until prompted to do so.

D.2.2.2


Introduction Application Selection is the transaction-processing phase in which the Cardholder System selects the application from the IC Card. Conditions of execution This phase is mandatory. Process description The Cardholder System shall perform Application Selection as prescribed by Part II of Book 1 To create the list of supported applications, the Cardholder System shall: • Examine the SET Initiation Message to determine the brands supported by the merchant. Use the BrandID—AID table to build the list of supported AIDs. If no mutually supported applications are found, the Cardholder System shall either: •

Automatically update the Brand—AID table.

•

Prompt the Cardholder to confirm the correct card has been inserted, and if so, update the Brand—AID table. Otherwise request the Cardholder to remove the card and return to the Card Selection phase. If after an update, a mutually supported application cannot be found, the Cardholder System shall request that the Cardholder remove the card and return to the Card Selection phase.

The Cardholder System shall display the application(s) as follows:

December, 2000 Annex D – Transaction Processing for Chip E-Commerce 1

2

115

If an Application Preferred Name (tag ‘9F12’) was provided by the card application in its response to the SELECT command, the Cardholder System shall display it to the Cardholder. Otherwise: the Cardholder System shall display the Application Label (tag ‘50’) that was provided by the card application in its response to the SELECT command. If an Issuer URL (tag ‘5F50’) was provided by the card application in its response to the SELECT command, the Cardholder System may use the Issuer URL to request an application logo and display that logo to the Cardholder in addition to the Application Preferred Name or Application Label. The Cardholder System shall decode the Issuer URL as prescribed by Annex E Issuer URL for Electronic Commerce.

D.2.2.3


Purpose Application Initiation is the transaction-processing phase during which the IC Card and the Cardholder System learn the details of the transaction and make an informed decision as to whether they wish to participate. Conditions of execution This phase is mandatory. Process description The Cardholder System shall initiate the application as prescribed by Section 6.1.. It shall assume the role of the “terminal” described therein.

D.2.2.4


Purpose Read Application Data is the transaction processing phase in which the Cardholder System reads the files and records of the card application. Conditions of execution This phase is mandatory. Process description The Cardholder System shall read the application data as prescribed section 6.2. It shall assume the role of the “terminal” described therein.

D.2.2.5


Purpose Cardholder Verification is the transaction-processing phase in which the Cardholder System retrieves information from the Cardholder that may verify their identity and either presents it to the card or transmits it to the issuer for verification.

116


Annex F – Electronic Commerce System Flow Diagram provides a flow diagram to assist the reading of this section. Conditions of execution The Cardholder System shall perform Cardholder Verification if bit 5 of byte 1 of the Application Interchange Profile is set to ‘1’. Process Description The Cardholder System shall perform the Cardholder Verification process as prescribed by section 6.5, assuming the role of the “terminal” described therein, with the following exceptions: 1

2

Determining Whether to Prompt for Off–line PIN Entry. When the method of Cardholder Verification requested by the card (as indicated by it’s CVRs) requires that the Cardholder provide his/her PIN for off–line verification by the card, the Cardholder System shall determine whether there is a mechanism for transport of the cryptogram to the issuer for authentication. If transport of the cryptogram is not available, the Cardholder System shall not prompt for off–line PIN entry, but shall attempt to process the next CVR. Cardholder applications shall support the following method and may support others. The Cardholder System shall search for the presence of the commonChip OID in the extension to Payment Gateway Certificate. If this OID is present, transport of the cryptogram is available. Determining Whether to Prompt for Online PIN Entry. When the method of Cardholder Verification requested by the card (as indicated by it’s CVRs) requires that the Cardholder provide his/her PIN for online verification by the issuer, the Cardholder System shall determine whether the Payment Gateway supports issuer verification of an online PIN. To do this, the Cardholder System shall search for the presence of the id–set–PIN–Any– Source OID in the extension to Payment Gateway Certificate. If this OID is available, the Cardholder System shall prompt for PIN entry. If this OID is not available, the Cardholder System shall not prompt for PIN entry, but shall attempt to process the next CVR.

Transmitting PIN Online The Cardholder System shall encipher and transmit the Cardholder’s PIN online as prescribed by the SET Online PIN Extension.

D.2.2.6


Purpose Terminal Action Analysis is the phase of transaction processing in which the Cardholder System requests an online authorisation of the transaction. In response, the card determines whether to decline the transaction off–line or to request an online authorisation.


117

Conditions of execution This phase is mandatory if the Payment Gateway supports the commonChip extension. Process description The Cardholder System shall perform Terminal Action Analysis as in section 6.7. The Cardholder System shall assume the role of the “terminal” described therein and behave just like that terminal with the following exceptions: 1.

Changes to Issuer and Terminal Action Code Processing: the Cardholder System shall not compare the Terminal Verification Results to the card’s Issuer Action Codes or to Terminal Action Codes.

2.

GENERATE AC Command: the Cardholder System shall tailor the GENERATE AC command by limiting the values of its reference control parameters to ARQC.

3.

Source of data requested in CDOL1: the Data Elements the Cardholder System transmits to the card in the data field of the GENERATE AC command shall be obtained from the sources indicated in Table D-3.

4.

Converting Cryptogram Data: some of the Data Elements the Cardholder System obtains for transmission to the card in the data field of the GENERATE AC command must be converted to formats the card understands as prescribed in Part I of this book.

Source of data requested in CDOL1 The Cardholder System shall obtain the data elements requested by the EMV IC Card in the CDOL1 from the following sources and transaction processing phases indicated below:

118

Annex D - Transaction Processing for Chip E-Commerce December, 2000 Data Element Amount, Authorised

Transaction Processing Phase SET Initiation

Source PurchAmt

Amount, Other

––––––––––––––––––– –

Cardholder System

Terminal Country Code

Purchase Initialization

Merchant certificate [merchcert.merchantdata.mer country]

Terminal Verification Results

––––––––––––––––––– –

Cardholder System

Transaction Currency Code

SET Initiation

PurchAmt

Transaction Date

Purchase Initialisation

PreqDate

Transaction Type

––––––––––––––––––– –

Cardholder System

Unpredictable Number


The Cardholder System shall generate the Unpredictable Number as follows: 1. Obtain the SET defined Data Element, XID (Transaction ID). 2. Divide the XID (from left to right) into five 4-byte blocks. 3. Exclusive-or the first block (leftmost) with the second block. 4. Exclusive-or the result from Step 3 with the third block. 5. Exclusive-or the result from Step 4 with the fourth block. 6. Exclusive-or the result from Step 5 with the fifth block. The 4–byte result of this operation is the Unpredictable Number.

Table D - 3 - Source of data requested in CDOL1


119

Converting CDOL1 data Before transmitting it to the card in the data field of the GENERATE AC command, the Cardholder System shall convert some of the source data referenced above as follows: Source Data PurchAmt

Conversion Procedure

Output

Extract Currency

Transaction Currency Code

PurchAmt

Extract Amount

Amount, Authorised

PreqDate

Extract YYYYMMDD from the PinitRes message and strip the first two digits to derive YYMMDD.

Transaction Date

Table D - 4 - Converting CDOL1 Data for Terminal Action Analysis

D.2.2.7

Issuer Script Processing and Completion

Purpose Issuer Script Processing and Completion is the transaction-processing phase in which the Cardholder System terminates the involvement of the Cardholder and the IC Card with the transaction. Conditions of executions This phase is mandatory. Process description The Cardholder System shall perform Issuer Script Processing and Completion according to the following conditions: 1.

2.

The card application declines the transaction. The Cardholder System shall terminate the transaction, inform the Cardholder that the purchase has been declined and that it is now permissible to remove the card from the Interface Device (IFD). The PInitRes indicates the Payment Gateway does not support the Common Chip Extension or The PRes message has been processed and the AuthCode indicates orderReceived, noReply, piAuthMismatch or systemError, or The Cardholder System does not receive a PRes message in a timely manner: The Cardholder System shall: • perform the processing prescribed by Section 7.11, with the following exception: the Cardholder System shall request an AAC and will assign

120

3.

Annex D - Transaction Processing for Chip E-Commerce December, 2000 the value ‘Z3’ to the Authorisation Response Code (tag ‘8A’) (Inform the Cardholder that it is now permissible to remove the card from the IFD). The PRes message has been processed and the AuthCode does not indicate orderReceived, noReply, piAuthMismatch or systemError. The Cardholder System shall: • Examine the contents of the acqCardExtensions of the PRes to determine whether Issuer Scripts (tag ‘71’ or ‘72’) are present. If scripts are present they are to be processed as Section 6.10. • Perform the processing prescribed by Section 6.11 (using any other EMV data from the acqCardExtensions), with the following exceptions. • The Cardholder System shall examine the AuthCode of PRes to determine which type of cryptogram it should request. If the AuthCode indicates declined, callIssuer, amountError, expiredCard, invalidTransaction, the Cardholder System shall request an AAC and will assign the value ‘05’ to the Authorisation Response Code (tag ‘8A’). If the AuthCode indicates approved, the Cardholder System shall request a TC and will assign the value ‘00’ to the Authorisation Response Code (tag ‘8A’). After receiving the card’s response to the second GENERATE AC command and after the execution of all Issuer Scripts present, inform the Cardholder that it is permissible to remove the card. The results of the second GENERATE AC are ignored.

D.2.3 Cardholder System—Merchant Server Interface This section describes the transaction processing phases that involve interaction between the Cardholder System and the Merchant Server. Phases of transaction processing that do not involve interaction between the Cardholder System and the Merchant Server are detailed in Section 2.6 and 2.8. This section describes the following transaction processing phases: D.2.7.1

SET Initiation: describes the SET Initiation Message used to invoke the Cardholder System.

D.2.7.2

Purchase Initialization Request & Response: describes the PInitReq and PInitRes messages, which support initialization of the SET protocol.

D.2.7.3

Purchase Request & Response: describes the PReq and PRes messages, which constitute the purchase transaction between the Cardholder System and Merchant.


D.2.3.1

121

SET Initiation

Purpose SET Initiation is the phase of a purchase transaction during which the Merchant Server invokes the Cardholder System and informs it of the transaction details and accepted payment brands. Conditions of use The Merchant Server shall initiate every SET purchase transaction. Creation of SET Payment Initiation message Merchant Servers shall create SET Payment Initiation messages as prescribed by External Interface Guide to SET Secure Electronic Commerce. Note: In order to provide the complete functionality of this specification, the URL in the SET–Brand header line in the SET Initiation message must reference a directory that contains the brandDat.mim file. When the merchant manages this directory, the Merchant Server shall retrieve the file from a directory managed by the brand and copy the file to its local directory. See Appendix 1 for more details. Processing of SET Initiation Message The Cardholder System shall process SET initiation messages as prescribed by External Interface Guide to SET Secure Electronic Commerce.

D.2.3.2

Purchase Initialisation

Purpose Purchase Initialization is the phase of a purchase transaction during which: 1. The Merchant Server obtains the information that it needs to understand the context of the transaction. 2. The Cardholder System obtains the information that it needs to create a purchase request, as well as authenticate the Merchant Server and Payment Gateway. Conditions of use The Cardholder System shall initialize every purchase transaction. Rules The mechanism that SET provides for purchase initialisation is the PInitReq and PInitRes messages. The Cardholder System shall create the PInitReq message as prescribed below. The Merchant Server shall process PInitReq and create PInitRes as prescribed by SET. The Cardholder System shall process PInitRes as prescribed by SET.

122


D.2.3.2.1

Cardholder System Creates PInitReq

Completing PInitReq The Cardholder System shall create PInitReq as prescribed by SET, with the following exceptions: Step 1 2

Action Obtain the IC Card specific data inputs to PInitReq from the card application. Convert the data objects obtained from the card to SET formats.

Obtaining Data Objects from IC Card The Cardholder System shall obtain the following data objects from the card application. The sources of these data objects and elements, i.e. the phase of transaction processing during which they are retrieved, are indicated below. Once converted, these data objects shall serve as inputs to the PInitReq message. SET Data Input Language

Corresponding Card Data Object Language Preference

BrandID BIN

Source

Tag

Application Selection phase

‘5F2D’

AID (of selected application)


‘4F’

PAN

Read Application data phase

‘5A’

Table D - 5 - IC Card Data inputs to PInitReq Note: Cardholder Systems designed for use in a private environment (a home PC for example) may provide an option to use a Cardholder–selected language rather than the IC Card’s language. Converting Data Objects to Data Inputs The Cardholder System shall convert the data objects obtained from the card as follows: Data Element PAN

Conversion Procedure Let the first six digits of the PAN constitute the BIN.

AID

Obtain the brand corresponding to this AID from the Brand—AID mapping table. Table D - 6 - Converting IC Card Data inputs to PInitReq

December, 2000 Annex D – Transaction Processing for Chip E-Commerce D.2.3.2.2

123

Cardholder System Processes PInitRes

Processing PInitRes The Cardholder System shall process the PInitRes as prescribed by SET with the following addition. The Cardholder System shall examine the Payment Gateway’s certificate to ascertain whether it supports the commonChip and onlinePIN extensions.

D.2.3.3

Purchase Request & Response

Purpose Purchase Request is the transaction-processing phase in which the Cardholder System requests the actual purchase from the merchant. Purchase Response is the transaction-processing phase in which the Merchant Server informs the Cardholder System of the status of the Purchase Request. Conditions of use The Cardholder System shall transmit the Purchase Request (PReq) message after initializing each purchase transaction. The Merchant Server may transmit the Purchase Response (PRes) message anytime after it receives the Purchase Request Message, even before it sends an Authorisation Request to the Payment Gateway. Rules The mechanism that SET provides for purchase request is the PReq and PRes messages. The Cardholder System shall create the PReq message as follows: If a SET Cardholder certificate associated with the selected account is available during the transaction, the Cardholder System shall create a PReqDualSigned message, otherwise it shall create a PReqUnsigned message as prescribed by this section. If the Cardholder Verification Method selected was Online PIN, the Cardholder System shall create and append the onlinePIN extension to the PReq message as prescribed in the SET Online PIN Extension. If the Terminal Action Analysis phase resulted in an ARQC or an AAR, the Cardholder System shall create and append the commonChip extension to the PReq message as prescribed below. The Merchant Server shall process the PReq and create a PRes as prescribed by SET. The Cardholder System shall process the PRes as prescribed by SET.

124


D.2.3.3.1

Cardholder System’s Creation of PReq

Completing PReq The Cardholder System shall create the PReq as prescribed by SET, making the following changes to the manner in which the Payment Instructions are created: Step 1 2

Action Obtain the IC Card specific data inputs to the Payment Instructions (PI). Convert the data objects obtained from card to SET required formats.

Obtaining Data Elements from IC Card The Cardholder System shall obtain the following data elements from the card application to serve as inputs to the PI. The sources of these data elements, i.e. the phase of transaction processing during which they are accessed, are indicated below. PI Input

Language

Corresponding Card Data Element Language Preference

Source

Tag


‘5F2D’

BrandID

AID (of selected application)


‘4F’

PAN

PAN


‘5A’

BIN

PAN


‘5A’

CardExpiry

Application Expiration Date


‘5F24’

Table D - 7 - IC Card Data inputs to Payment Instructions

Converting Data Elements to PI Inputs The Cardholder System shall convert the Data Elements obtained from the card as follows:

December, 2000 Annex D – Transaction Processing for Chip E-Commerce Data Object PAN

Conversion Procedure The first six digits of the PAN identify the BIN.

AID

Obtain the brand corresponding to this AID from the Brand—AID mapping table. Annex defines the format for Application Expiration Date to be YYMMDD. However, the SET Specification defines the format for CardExpiry to be YYYYMM. Therefore, the Cardholder System shall reformat Application expiration Date as prescribed below: Drop DD. Use same MM. 1. Convert the YY value to a four–digit year as prescribed by EMV.

Application Expiration Date

125

Table D - 8 - Converting IC Card Data to PI Inputs D.2.3.3.2

Cardholder System’s Creation of Common Chip Extension

When required, the Cardholder System shall append the commonChip extension to the PIHead portion of the PReq message. It shall code this extension as prescribed by SET Common Chip Extension. The EMVData field of the extension must include the Data Elements listed in the table below, when available for the transaction. The data that appears in the EMV data field can be in any order but must be TLV encoded and bit–wise identical to the fields presented to the IC Card. The Cardholder System shall obtain these Data Elements from the source identified in the last column of the table.

126

Annex D - Transaction Processing for Chip E-Commerce December, 2000 Name Amount, Authorised Amount, Other Application Cryptogram Application Interchange Profile Application PAN Sequence Number Application Transaction Counter Cryptogram Information Data Issuer Application Data Terminal Country Code Terminal Verification Results Track–2 Equivalent Data

Transaction Currency Code Transaction Date Transaction Type Unpredictable Number

Format

Length

‘9F02’ ‘9F03’ ‘9F26’ ‘82’

Tag

n n12 b b

6 6 8 2

SET Initiation Phase Cardholder System Terminal Action Analysis Application Initiation Phase

Sources

'5F34'

n2

1


‘9F36’

b

2


‘9F27’

b

1


‘9F10’ ‘9F1A’ ‘95’

b n b

Var. up 32 2 5

Terminal Action Analysis Purchase Initialisation Terminal Action Analysis

'57'

b

Var. up 19

‘5F2A’ ‘9A’ ‘9C’ ‘9F37’

n n n b

2 3 1 4

Read Application Data Phase (the Cardholder System shall set the PAN and Expiration Date in this data object to zero before transmitting it in the extension) SET Initiation Phase Purchase Initialisation Phase Cardholder System Terminal Action Analysis

Table D - 9 - commonChip extension data and its sources

D.2.4 Merchant Server—Payment Gateway Interface This section describes the transaction processing phases that involve interaction between the Merchant Server and the Payment Gateway. It defines the messages through which Merchant Servers and Payment Gateways communicate to complete a phase of transaction processing. Phases of transaction processing that do not involve interaction between the Merchant Server and the Payment Gateway are detailed in section 2.6 and section 2.7. This section describes the following phases of transaction processing: D.2.4.1

Authorisation Request & Response: describes the AuthReq and AuthRes messages, which support the authorisation stage of the payment transaction.

D.2.4.2

Capture Request & Response: describes the CapReq and CapRes messages, which support the capture stage of the purchase transaction.


D.2.4.1

127

Authorisation Request and Response

Purpose Authorisation Request is the phase in which the Merchant Server requests an authorisation for the Cardholder’s intended purchase. Authorisation Response is the phase in which the Payment Gateway informs the Merchant Server whether the purchase has been approved or declined by the issuer. It also provides the merchant with the data necessary to request the capture of the transaction. Conditions of execution The Merchant Server shall transmit the Authorisation Request (AuthReq) message after it receives a valid purchase request from the Cardholder System. The Payment Gateway shall transmit the Authorisation Response (AuthRes) message after it has received an authorisation response. Rules The Merchant Server shall create the AuthReq as prescribed by SET. The Payment Gateway shall process AuthReq and may create AuthRes as prescribed below. The Merchant Server shall process AuthRes as prescribed by SET.

D.2.4.1.1

Payment Gateway Processing of AuthReq

Payment Gateway processes AuthReq The Payment Gateway shall process the AuthReq as follows: 1 Process AuthReq as prescribed by SET 2 If the PIHead contains the commonChip extension then: • Re–calculate the Unpredictable Number and compare the fresh results with the Unpredictable Number contained in the commonChip extension. • If the recalculated and transmitted Unpredictable Numbers do not match, then proceed to AuthRes, otherwise continue. 3

Request issuer authorisation.

Re–calculating Unpredictable Number To ensure the cryptogram is fresh, the Payment Gateway shall recalculate the Unpredictable Number transmitted in the extension as prescribed below. The 4–byte result of this operation is the Unpredictable Number: 1 Divide the XID (from left to right) into five 4–byte blocks. 2

Exclusive–or the first block (leftmost) with the second block.

3

Exclusive–or the result from Step 2 with the third block.

4

Exclusive–or the result from Step 3 with the fourth block.

5

Exclusive–or the result from Step 4 with the fifth block.

128


D.2.4.1.2

Payment Gateway Creation of AuthRes

Completing AuthRes The Payment Gateway shall create AuthRes as prescribed by SET with the following exception: 1

If the recalculated and transmitted Unpredictable Numbers do not match, the Payment Gateway shall return an Authorisation Response with AuthCode set to piAuthMismatch.

2

If the issuer transmitted Issuer Authentication Data or Issuer Script(s) in its response to the Payment Gateway’s earlier authorisation request, the Payment Gateway shall transmit this information to the Cardholder System through the acqCardExtensions in the SET AcqCardMsg.

3

If the Merchant Server is to supply the Payment Gateway or the acquirer with the data that is required to capture approved transactions, the Payment Gateway must transmit to the merchant the additional data required to capture transactions in which the cryptogram is used to verify the authenticity of the card.

Modifications to SET Acquirer Card Message The Payment Gateway must be able to transmit Issuer Authentication Data (tag ‘91’) and Issuer Script(s) (tag ‘71’ or ‘72’) to the Cardholder System by including the acqCardExtensions as defined in the SET Common Chip Extension. Transmitting capture data to the Merchant Server Merchants who supply the Payment Gateway or the acquirer with the data required to capture approved transactions must provide the EMV data used to verify the authenticity of the card. This additional data is the emvData field of the commonChip extension. To be able to provide this additional data, the Merchant Server must have received it from the Payment Gateway in one of two fields of the AuthRes message. If the Payment Gateway wishes to enable the Merchant Server to decrypt the emvData, to capture outside of SET for example, the Payment Gateway must transmit it as an extension to the AuthResPayload field of AuthRes. If not, the Payment Gateway may transmit it via the TokenOpaque field of the Capture Token. Since TokenOpaque is an open type (containing DER-encoded data) meaningful only to the Payment Gateway, to transport EMVData, ChipTokenOpaque may be used as an alternative definition for TokenOpaque, where: ChipTokenOpaque ::= SEQUENCE { emvData EMVData, tokenOpaque TokenOpaque }.


D.2.4.2

129

Capture Request and Response

Purpose Capture Request is the phase of transaction processing in which the merchant requests clearing, i.e., financial payment, for one or more previously authorized transactions. Capture response is the phase of transaction processing in which the Payment Gateway notifies the Merchant Server of the status of its capture request. Conditions of execution The means by which the Merchant Server captures transactions and the times at which it does so may vary. For example, a merchant may delay the clearing of a transaction and when clearing the transaction, the merchant may clear it out–of– band to SET. Rules The contents of the EMVData field of the commonChip extension should be included in Payment System messages related to the original authorisation request (e.g., subsequent authorisation requests/reversals needed to process split and recurring payments, and clearing messages in general.) Exactly how this data ultimately reaches the clearing and settlement system depends upon the processing relationships and capabilities of the Merchant Server, Payment Gateway, merchant back office, and the acquirer’s system.

130



December, 2000

Annex E – Issuer URL for Electronic Commerce

131

Annex E - Issuer URL for Electronic Commerce Introduction The issuer Uniform Resource Locator (URL), located in the ADF, points to the location of (a) brand or financial institution logo(s) that the Cardholder System may retrieve for display to the Cardholder during the transaction. Structure of Issuer URL The structure of the Issuer URL is illustrated below. It consists of two parts, the Issuer’s server, which is identified by its Scheme and Authority, and an ApplicationID: URL

://

Scheme

Example: http://

Authority

Example: www.bankname.com/

ApplicationID

Examples: Brand–xCreditClassic, or a reference number. Table E - 1 - Issuer URL data

Example of processing an Issuer URL In order to retrieve the logo to be displayed, the Cardholder System shall generate the Issuer URL as follows: 1

Read the URL: e.g. http://www.bankname.com/Brand—xCreditClassic.

2

Append the filename for the desired logo prior to sending the request to create: http://www.bankname.com/Brand—xCreditClassic/small.gif

For more information The graphic formats for the logo are defined in Appendix F of the SET 1.0 Specification. For more information regarding URL, see IETF RFC 1738 “Uniform Resource Locator (URL).”

132

Annex E – Issuer URL for Electronic Commerce

THIS PAGE LEFT INTENTIONALLY BLANK.

December, 2000

December, 2000 Annex F - E-Commerce Cardholder System Flow Diagram

Annex F -

133

Electronic Commerce Cardholder System Flow Diagram

Introduction This appendix illustrates the flow of the Cardholder System’s processing steps. No

SET Initiation Message

Card Selection


Is Application Selection successful

Purchase Initialization Response

Purchase Initialization Request

Read Application


Yes

Is Online PIN requested

No

Yes

No

Is onlinePIN extension supported

Yes

No

Is commonChip extension supported

Yes

Is Off-line PIN requested

Is Online PIN requested

No

Yes

Is onlinePIN extension supported

Yes


Yes



Generate Online PIN extension


No

Is the Application Cryptogram an AAC

No

Yes

No Generate commonChip extension

Is a Cardholder Certificate available

No

Yes PReqDualSigned

PReqUnSigned

Purchase Response

Issuer Script Processing and Completion

Figure F- 1 - Cardholder System Flow Diagram

Generate onlinePIN extension

134

Annex F - E-Commerce Cardholder System Flow


December, 2000

December, 2000

Annex G - Cardholder System Implementations

Annex G -

135

Electronic Commerce Cardholder System Implementations

G.1 Overview Introduction This specification defines the integration of EMV card technology and SET electronic commerce technology. In it, the communication between the card and the merchant is managed by a system called the Cardholder System. Before the development of Chip Electronic Commerce, a SET Cardholder System was usually a software application stored on a PC that acted as a helper to a Web browser. This application is commonly referred to as a SET “wallet”. The design of a Cardholder System however, is not limited to a single device or implementation. A growing number of implementations experiment with clientserver architectures, thereby gaining advantages such as simplified distribution and upgrades. Similarly, certain Chip Electronic Commerce implementations have also been designed to provide an authentication migration path, whereby a SET cardholder certificate is used should the merchant and their acquirer not support the IC Card’s cryptogram. This specification does not specify or recommend any particular implementation or describe the merits of any implementation; rather, it aims to define a high level model of the EMV Cardholder System which members and vendors can use as part of their design process. The aim of this informational appendix is to encourage members and vendors to experiment with different technical configurations based upon this specification. This appendix also explores two sample implementations that address the issue of authenticating an chip card initiated transactions to a merchant and acquirer who are not chip capable. It is offered by the EMVCo working group as an aid to the ongoing SET Technical Advisory Group efforts to define the technical requirements for server based wallets. Definition of Cardholder System The EMV Cardholder System is any combination of hardware and software that allows a cardholder to conduct an EMV compliant SET payment with a merchant’s system. It is an abstract term covering any number of logical components that reside on a single physical device, or are distributed across any number of connected devices.

136


December, 2000

Cardholder System components The EMV Cardholder System can be divided into seven functional components and a internal communication protocol defining the interaction of each component. The components are: • • • • • • • •

Cardholder interface Cardholder database SET message manager SET private key manager EMV message manager IC Card Interface device PIN entry device (optional) Internal communication protocol

Components The relationship between components of the EMV Cardholder System is depicted below:

Cardholder interface

SET Private Key Manager

IFD EMV Device Manager

SET Message Manager

Cardholder Device Cardholder

EMV IC Card

EMV

PIN Device

SET

SET Merchant Server or Certificate Authority

Figure G - 1 - Cardholder System components

Overall guideline The Cardholder System, being the sum of the components, must minimize the risk of limited or systemic compromise. The specific security requirements must be appropriate for the implementation of the system as a whole. For example, the risks and therefore the security requirements for a classic SET application on a personal computer will be less than those for a server based Cardholder System designed to serve hundreds of cardholders.

December, 2000


137

Cardholder interface and device The Cardholder interface and device is responsible for the system’s input/output (such as keyboard, screen, and graphic user interface) allowing the Cardholder to interact with the system. The Cardholder interface and device must protect the Cardholder’s input, as well as the display or output of system information in accordance with industry best practice. Cardholder database The Cardholder database is responsible for the management of all Cardholder data, both payment data and non–payment data, such as a telephone number. Some configurations may store this data; others might hold it only for the duration of a transaction Cardholder data must be processed and stored in a manner that secures the confidentiality and integrity of sensitive data (both personal and payment related, such as PAN, PANSecret and Expiry) from external and internal attacks. SET message manager The SET message manager is responsible for the SET message interaction between a Merchant Server and Cardholder Certificate Authority. The SET Message Manager shall be capable of interfacing with a SET Merchant Server or Certificate Authority as defined by the SET Specification. SET private key manager The SET private key manager is responsible for the use and security of the SET Cardholder private key. The SET Private Key Manager, in conjunction with the SET Message Manager, must process certificate request and purchase request signing operations in a manner that assures the security of the private key.

EMV manager The EMV manager is responsible for the EMV message interaction between an EMV Device and Card. The EMV Manager must, at a minimum, support the EMV Commands, and ChipEC protocols defined in the Chip Electronic Commerce Specification. IC Card interface device (IFD) The IC Card Interface device (IFD) is a physical card–reading device that is responsible for allowing the EMV manager to communicate with an EMV card. The IC Card Interface device must, at a minimum, be an EMV level 1 compliant card reader capable of interfacing with the EMV manager.

138


December, 2000

PIN entry device (optional) The PIN entry device, which is optional, is a physical Cardholder input device capable of accepting the entry of a PIN. The PIN entry device must comply with applicable Payment System requirements and industry best practices. Internal communication protocol The Internal Communication Protocol is responsible for the communication between the Cardholder System components. A Cardholder System may posses one or both types of the communication protocols described below. Internal communications between interconnected devices. Components that reside in different devices must communicate in a manner that ensures that the information is passed in a timely, reliable and secure manner. It must also ensure the integrity of the individual components and their host device. At a minimum, sensitive payment data, such as PAN, Expiry and Track 2 equivalent data, should be protected to the same degree as they are in a SET message. Internal communications within a device. Components within a device must communicate in a manner that ensures the security of both the information passed, and the integrity of the components themselves. The implementation should follow established best practices for financial applications running on that device/Operating System. Organisation Annex G includes the following sample implementations: Annex G.2 Hosted Cardholder System: A sample implementation of a client–server based Cardholder System where the majority of the Cardholder System components reside on the server. It is designed to provide Cardholder authentication either using a cryptogram, or for those acquirers who have yet to migrate to EMV, a SET Cardholder certificate. Annex G.3 Thick Client Cardholder System: A sample implementation of a client–server based Cardholder System where the majority of the Cardholder System components reside on the client. It is designed to provide Cardholder authentication using a cryptogram, and/or a SET Cardholder certificate.

December, 2000


139

G.2 Hosted Cardholder System Client–server based Cardholder System This implementation explores hosting the majority of the SET Cardholder System components on a centralized server. This can facilitate the update and management of a large number of Cardholder Systems as most of their functionality has been concentrated on the server. Furthermore, as the installation of a “thin” Cardholder Client application is less complex, it is expected that the deployment and Cardholder usage will increase. Component allocation This implementation allocates the Cardholder System components as follows: Component Cardholder interface

Location Client

Cardholder database

Server

SET message manager

Server

SET private key manager

Server

EMV manager

Client

EMV device

Client

PIN entry device (optional)

Client

Internal communication protocol

Shared

Description of Hosted Cardholder System example The components interact as follows: Step 1 2

3 & 4

5

Description The SET Merchant Server sends a standard SET Initiation message. The Chip enabled Cardholder Client forwards the wake–up message to the Cardholder Server requesting that it complete a standard SET transaction. The Cardholder uses a cryptogram as a key to access the server. The Cardholder Server having received the Client request message, validates the cryptogram by contacting the issuer through an out of band mechanism, and if successful, uses the information in the wakeup message to conduct a SET transaction on the Cardholder’s behalf. Depending on the server’s capabilities, a certificate and/or a cryptogram may be used in the Purchase Request. Upon the completion of the transaction, the Cardholder Server sends a purchase response message to the Cardholder Client informing it of the transaction results.

140


December, 2000

Cardholder Server

Purchase Request +cryptogram Purchase Response

Cardholder Client

SET Initiation (Wake-up)

EMV

Figure G - 2 - Hosted Cardholder System example

SET Merchant Server

141


December, 2000

G.3 Thick Client Cardholder System Client–server based Cardholder System (thick client) This example implementation explores hosting the majority of the SET Cardholder System functions on the Cardholder Client, while the server provides a specialized service to the client. The example below describes a server that manages the certificate request and signing processes for a PReqDualsigned transaction. Note, in this example the certificate and private key are not stored on the Cardholder Client. This implementation might suit markets where some SET merchant/acquirers do not support EMV transactions and where a hosted wallet is not considered appropriate. This configuration may also allow the server to be phased out once EMV is universally accepted. Component allocation This implementation allocates the Cardholder System components as follows: Component Cardholder interface

Location Client

Cardholder database

Client

SET message manager

Client

SET private key manager

Server

EMV manager

Client

EMV device

Client

PIN entry device (optional)

Client

Internal communication protocol

Shared

Description of Thick Client example The components interact as follows: Step 1 2

Description The SET Merchant Server sends a standard SET Initiation message. The Cardholder Client sends a standard SET Purchase Initialization Request message indicating which payment brand is being used and receives a standard response from the merchant.

142


December, 2000

3

The Chip enabled Cardholder System determines from the Initialization Response if the merchant/acquirer supports EMV. If they do, the transaction will continue as a ChipEC transaction and the server is not required. If they do not, the Cardholder Client generates the Payment Information (Payment information to be signed Data Element, PITBS) for the SET Purchase Request and the sends it to the server as part of a signing request to the server using a cryptogram as the authentication data.

4

The server receives the request for authentication, and once the cryptogram has been verified by the issuer using an out of band mechanism, signs the PITBS data and returns it along with a Cardholder certificate (containing the Cardholder’s public key.)

5

The Cardholder System continues the transaction as a standard SET transaction signed with a Cardholder certificate.

Cardholder Server

Signing Request +cryptogram

Signing Response +Certificate SET Initiation (Wake-up)

Cardholder Client

SET PInitReq/Res PReq/Res (DualSigned)

EMV

Figure G - 3 - Thick Client example

SET ChipSET Mercant Merchant Server

Book 3

Recommend Documents