PCI Watch

Tracking changes across the Payment Card Industry

SB nº SU-25 : Common Core Definitions (Spec Change)

v1.0 Specification Bulletins

Specification Update Bulletin No. 25 Second Edition April 2004 This Bulletin describes changes to the EMV Integrated Circuit Card Specifications for Payment Systems. The contents of this bulletin have immediate effect. The changes to the specification have been made in response to comments received following the publication of Draft Specification Update Bulletin No. 25 on the EMVCo website. Common Core

Definitions

Applicability

This Specification Update Bulletin applies to:

  • EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Books 1 through 4

Related Documents

This Bulletin should be read in conjunction with:

  • EMVCo Specification Update Bulletin No. 26, Master Key Derivation Option
  • EMVCo Specification Update Bulletin No. 27, ARPC Generation Option
  • EMVCo Specification Update Bulletin No. 28, Secure Messaging Chaining
  • EMVCo Draft Specification Update Bulletin No. 34, Format 1 Secure Messaging Confidentiality In order to simplify implementations and enhance global interoperability of Integrated Circuit Card implementations, these Common Core Definitions specify a minimum common set of card application implementation options, card application behaviours, and data element definitions sufficient to accomplish an EMV transaction. The following updates provide four new sections, one for each book of the EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0. To be compliant with the Common Core Definitions, an implementation shall implement all the additional requirements in the Common Core Definitions section of all four books of the EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0. Terminals certified to be compliant with the existing EMV Specifications will, without change, accept cards implemented according to the Common Core Definitions, since the This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 Common Core Definitions are supported within the existing EMV requirements. Card support for the Common Core Definitions is optional. If implemented, the Common Core Definitions are in addition to the requirements specified in EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Books 1 through 4. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 Please add the following section to EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 1. Common Core Definitions This section is an optional extension to Book 1 of the EMV specifications, to be used when implementing the Common Core Definitions (CCD). It is to be used in conjunction with the EMV specifications and the Common Core Definitions section of each book of the EMV specifications. These Common Core Definitions specify a minimum common set of card application implementation options, card application behaviours, and data element definitions sufficient to accomplish an EMV transaction. Terminals certified to be compliant with the existing EMV Specifications will, without change, accept cards implemented according to the Common Core Definitions, since the Common Core Definitions are supported within the existing EMV requirements. To be compliant with the Common Core Definitions, an implementation shall implement all the additional requirements in the Common Core Definitions sections of all four books of EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0. The format for this section follows. Each section heading refers to the section in this book of the EMV specifications to which the additional requirements apply. The text defines requirements for a common core implementation, in addition to the requirements already specified in the referenced section of EMV. Part II – Files, Commands and Application Selection 6.1.4 Directory Structure The directory structure within the PSE shall not contain any "optional additional directories introduced by directory definition files (DDF)".

7.3.5 Processing State Returned in the Response Message The ICC shall support partial name selection and shall accept SELECT command messages containing at least the 5 high-order bytes of the DF name (RID). Select Next functionality shall be supported.

8.2.2 Structure of the Payment Systems Environment If the card contains a PSE, the PSE shall not contain a DDF. A graphic example of the internal logic structure of a CCD-compliant card can be found in EMV Book1 Appendix C, figure C2, where DDF1 is the PSE.

8.2.3 Coding of a Payment System’s Directory A PSE Directory Record shall only contain ADF entries; DDF entries are not allowed. Each record in the Payment Systems Directory shall be formatted as in Table CCD – 1: This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

Tag Data ‘70’ Length (L) Tag Length of Directory ‘61’ directory entry 1 entry 1 (ADF)... Tag ‘61’ Length of directory entry n Directory entry n (ADF) Table CCD – 1 - PSE Directory Record Format for a CCD-Compliant Card This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

Please add the following section to EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 2. Common Core Definitions This section is an optional extension to Book 2 of the EMV specifications, to be used when implementing the Common Core Definitions (CCD). It is to be used in conjunction with the EMV specifications and the Common Core Definitions section of each book of the EMV specifications. These Common Core Definitions specify a minimum common set of card application implementation options, card application behaviours, and data element definitions sufficient to accomplish an EMV transaction. Terminals certified to be compliant with the existing EMV Specifications will, without change, accept cards implemented according to the Common Core Definitions, since the Common Core Definitions are supported within the existing EMV requirements. To be compliant with the Common Core Definitions, an implementation shall implement all the additional requirements in the Common Core Definitions sections of all four books of EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0. The format for this section follows. Each section heading refers to the section in this book of the EMV specifications to which the additional requirements apply. The text defines requirements for a common core implementation, in addition to the requirements already specified in the referenced section of EMV.

6.5.1 Dynamic Signature Generation (DDA) An ICC that supports DDA shall contain a DDOL. The DDOL shall contain only the Unpredictable Number generated by the terminal (tag '9F37', 4 bytes binary).

6.6.1 Dynamic Signature Generation (CDA) For a CCD-compliant application that supports CDA, the following requirements shall apply. The ICC response to the GENERATE AC command for a TC or ARQC shall contain only the data objects specified in Table CCD – 1. Tag ‘9F27’ ‘9F36’ ‘9F4B’ ‘9F10’ Length 1 2 NIC 32 Value Cryptogram Information Data Application Transaction Counter Signed Dynamic Application Data Issuer Application Data Presence M M M M Table CCD –1

  • Data Objects Included in Response to GENERATE AC for a TC or ARQC 3. If the ICC responds with an AAC, the ICC response shall be coded according to format 2 as specified in Part I of Book 3 of these specifications and shall contain only the data elements specified in Table CCD – 2. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 Tag ‘9F27’ ‘9F36’ ‘9F26’ ‘9F10’ Length 1 2 8 32 Value Cryptogram Information Data Application Transaction Counter Application Authentication Cryptogram Issuer Application Data Presence M M M M Table CCD – 2
  • Data Objects Included in Response to GENERATE AC for an AAC 8 Application Cryptogram and Issuer Authentication 8.1.1 Data Selection The set of data elements to be included in the Application Cryptogram generation for a cryptogram defined by the Common Core Definitions with a Cryptogram Version of ‘4’ is specified in Table CCD – 3. The data elements shall be included in the order shown in Table CCD – 3. Value Amount, Authorised (Numeric) Amount Other (Numeric) Terminal Country Code Terminal Verification Results Transaction Currency Code Transaction Date Transaction Type Unpredictable Number Application Interchange Profile Application Transaction Counter Issuer Application Data Source Terminal Terminal Terminal Terminal Terminal Terminal Terminal Terminal ICC ICC ICC Table CCD – 3 – Set of Data Elements for Application Cryptogram Generation 8.1.2 Application Cryptogram Algorithm The 8-byte Application Cryptogram shall be generated using the session key derivation method specified in Annex A1.3; and the MAC algorithm specified in Book 2, Annex A1.2 and ISO/IEC 9797-1 Algorithm 3 with DES, and s=8.

8.2 Issuer Authentication The CCD-compliant application shall support Issuer Authentication according to ARPC Method 2 specified in section 8.2.2.

8.2.2 ARPC Method 2 For a cryptogram defined by the Common Core Definitions with a Cryptogram Version of ‘4’, the Proprietary Authentication Data element shall be 0 bytes long. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

For a cryptogram defined by the Common Core Definitions with a Cryptogram Version of ‘4’, the Card Status Updates (CSU) data element shall be coded according to Book 3, CCD section, Annex C.9.

8.3 Key Management For a cryptogram defined by the Common Core Definitions with a Cryptogram Version of ‘4’; the Option B method described in Book 2, Annex 1.4.2 shall be used to derive the ICC Master Key.

9.1 Secure Messaging All commands using Secure Messaging shall use Secure Messaging Format 1 as described in EMV 2000, Book 2.

9.2 Secure Messaging for Integrity and Authentication 9.2.1 Command Data Field All commands using Secure Messaging for integrity and authentication shall use Secure Messaging Format 1 as described in EMV 2000, Book 2, section 9.2.1.1.

9.2.1.1 Format 1 All command data shall be included in the computation of the MAC. Data enciphered for confidentiality shall be encapsulated with Tag '87'. Data not enciphered for confidentiality shall be encapsulated with Tag '81'. The CCD-compliant application shall accept 4-byte MACs, and the Issuer can only rely on support of 4-byte MACs.

9.2.2 MAC Session Key Derivation For an application with a cryptogram defined by the Common Core Definitions with a Cryptogram Version of ‘4’, the MAC Session Key shall be derived using the method specified in Annex A1.3. The branch factor, b, shall be 4. The height of the tree, H, shall be 8. The initializing value, IV, shall be zero.

9.2.3 MAC Computation Secure Messaging is according to Secure Messaging Format 1. The CCD-compliant application shall accept 4-byte MACs, and the Issuer can only rely on support of 4-byte MACs.

9.2.3.1 Format 1 MAC Chaining All commands using Secure Messaging for integrity and authentication shall chain the MACs from one command to the next according to the method recommended in EMV 2000, Book 2, section 9.2.3.1. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

9.3 Secure Messaging for Confidentiality 9.3.1 Command Data Field All commands using secure messaging for confidentiality shall use Secure Messaging Format 1 as described in EMV 2000, Book 2, section 9.3.1.1.

9.3.1.1 Format 1 Data enciphered for confidentiality shall be encapsulated with Tag '87'. Data that is enciphered in the issuer script command data field shall always be padded before encipherment. The Padding Indicator byte shown in Figure 5 shall be included and shall be set to the value '01' to indicate padding is present.

9.3.2 Encipherment Session Key Derivation For an application with a cryptogram defined by the Common Core Definitions with a Cryptogram Version of ‘4’, the Encipherment Session Key shall be derived using the method specified in Annex A1.3. The branch factor, b, shall be 4. The height of the tree, H, shall be 8. The initializing value, IV, shall be zero.

9.3.3 Encipherment/Decipherment Encipherment/decipherment of the command data field shall use the Cipher Block Chaining (CBC) Mode described in Annex A1.1 with the Triple DES algorithm specified in Annex B1.1. The Padding Indicator byte is set to the value '01' to indicate that padding is present.

9.4 Key Management For an application with a cryptogram defined by the Common Core Definitions with a Cryptogram Version of ‘4’, the Option B method described in Book 2, Annex A1.4.2 shall be used to derive the ICC MAC and Encipherment Master Keys. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

Please add the following section to EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 3. Common Core Definitions This section is an optional extension to Book 3 of the EMV specifications, to be used when implementing the Common Core Definitions (CCD). It is to be used in conjunction with the EMV specifications and the Common Core Definitions section of each book of the EMV specifications. These Common Core Definitions specify a minimum common set of card application implementation options, card application behaviours, and data element definitions sufficient to accomplish an EMV transaction. Terminals certified to be compliant with the existing EMV Specifications will, without change, accept cards implemented according to the Common Core Definitions, since the Common Core Definitions are supported within the existing EMV requirements. To be compliant with the Common Core Definitions, an implementation shall implement all the additional requirements in the Common Core Definitions sections of all four books of EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0. The format for this section follows. Each section heading refers to the section in this book of the EMV specifications to which the additional requirements apply. The text defines requirements for a common core implementation, in addition to the requirements already specified in the referenced section of EMV. Part I – Data Elements and Commands 2.2 Response APDU Format For the following commands used during transaction processing, the body of the response APDU is a constructed data object with tag equal to ’77’ of which the value field may contain one or more BER-TLV coded data objects.

  • GENERATE AC
  • GET PROCESSING OPTIONS
  • INTERNAL AUTHENTICATE TAG Value ‘77’ Response Message Template Format 2 Table CCD – 1 – Body of Response APDU Structure 2.5.4 EXTERNAL AUTHENTICATE Command-Response APDUs 2.5.4.1 Definition and Scope The CCD-compliant application shall support Issuer Authentication using the 2nd GENERATE AC command. The CCD-compliant application shall indicate the EXTERNAL AUTHENTICATE command is not supported in EMV applications by setting bit 3 in Byte 1 of the AIP to '0'. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

2.5.5 GENERATE APPLICATION CRYPTOGRAM CommandResponse APDUs 2.5.5.1 Definition and Scope The CCD-compliant application shall not generate an Application Authorization Referral (AAR) cryptogram type. The CCD-compliant application shall support Issuer Authentication using the 2nd GENERATE AC command.

2.5.5.3 Data Field Sent in the Command Message CDOL2 shall include Tag '91' (Issuer Authentication Data). In the Common Core Definitions Version 4.1, the length of the Issuer Authentication Data element specified in the CCD Annex and section 8.2.2 of Book 2 shall be 8 bytes.

2.5.5.4 Data Field Returned in the Response Message The response message shall be a BER-TLV coded constructed data object introduced by tag ‘77’ and contains only the data shown in Table CCD – 2. Tag ‘9F27’ ‘9F36’ ‘9F26’ ‘9F10’ Value Cryptogram Information Data Application Transaction Counter Application Cryptogram Issuer Application Data Table CCD – 2

  • Format 2 GENERATE AC Response Message Data Field The required data elements for the response returned in an envelope as specified for the CDA feature described in section 6.6 of Book 2 are shown in Tables CCD – 1 and CCD – 2 in the CCD Annex to Book 2. The Cryptogram Information Data returned in the GENERATE AC response message is coded according to Table CCD – 3: b8 b7 b6 b5 b4 b3 b2 b1 0 0 0 1 1 0 1 1 0 0 0 0 0 0 Meaning AAC TC ARQC RFU Payment System specific cryptogram No advice required No information given Table CCD – 3
  • Coding of Cryptogram Information Data 2.5.8 GET PROCESSING OPTIONS Command-Response APDUs 2.5.8.2 Command Message The CCD-compliant application shall not preclude support for PDOL. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

2.5.8.4 Data Field Returned in the Response Message The response message shall be a BER-TLV coded constructed data object introduced by tag ‘77’ and contains only the data shown in Table CCD – 4. Tag Value ‘82’ Application Interchange Profile ‘94’ Application File Locator Table CCD – 4 Format 2 GET PROCESSING OPTIONS Response Message Data Field 2.5.9 INTERNAL AUTHENTICATE Command-Response APDUs 2.5.9.4 Data Field Returned in the Response Message The response message shall be a BER-TLV coded constructed data object introduced by tag ‘77’ and contains only the data shown in Table CCD – 5. Tag Value ‘9F4B’ Signed Dynamic Application Data Table CCD – 5 Format 2 Internal Authenticate Response Message Data Field Part II – Debit and Credit Application Specification 3.2 Data Retrievable by GET DATA Command The ICC shall support the GET DATA command for retrieval of the primitive data object with Tag ‘9F17’ (PIN Try Counter).

5.2.2 Transaction Certificate Data The CCD-compliant application shall not contain a TDOL. The CCD-compliant application shall not request the terminal to generate a TC Hash Value (that is Tag '97' shall not be included in CDOL1 or CDOL2). The following Section 5.2.3 applies to a CCD-compliant application.

5.2.3 Common Core Definitions Card Verification Results In response to the GENERATE AC command and as part of the Issuer Application Data, the CCD-compliant application shall return the Card Verification Results (CVR). The CVR includes information for the issuer regarding the results of Card Risk Management processing and application processing. The format of the CVR for a CCD-compliant application is specified in CCD Annex C.8.3. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

5.2.3.1 Options Related to Setting/Resetting of Counters and Indicators The Issuer shall have the option to specify whether or not a new card is required to set the Go Online on Next Transaction bit. The Issuer shall have the option to specify whether or not Issuer Authentication is required by the CCD-compliant application for completion of an online transaction to be considered successful. If Issuer Authentication is not required by the CCD-compliant application for completion of an online transaction to be considered successful, the Issuer shall have the option to specify whether or not Issuer Authentication is required by the CCD-compliant application for resetting the count of script commands processed with secure messaging and all the following non-velocity-checking indicators:

  • Issuer Authentication Failed
  • Last Online Transaction Not Completed
  • Issuer Script Processing Failed
  • Go Online on Next Transaction Was Set If Issuer Authentication is not required by the CCD-compliant application for completion of an online transaction to be considered successful, the Issuer shall have the option to specify whether or not Issuer Authentication is required by the CCD-compliant application for resetting the velocity-checking offline transaction count(s) and cumulative offline amount(s). The Issuer shall have the option to indicate whether or not the application shall use the Update Counters bits in the CSU to update the velocity-checking count(s) and cumulative amount(s) associated with the offline transaction limits referred to in bits b8 - b5 of Byte 3 of the CVR, if the CSU Created by Proxy for the Issuer bit in the CSU is set to '1'. If the CSU Created by Proxy for the Issuer bit is set to '1' in the CSU, and the Issuer specifies that Update Counters shall not be used, the Issuer shall have the option to indicate whether the application shall:
  • not update the offline counters
  • set the offline counters to zero
  • set the offline counters to the upper offline limits
  • add the transaction to the offline counter(s).

5.2.3.2 Setting and Resetting of Bits in the CVR The following describes the conditions under which each bit in the CVR of a Common Core Definitions card is set or reset. Application Cryptogram Type Returned in Second GENERATE AC These bits shall be set in the first GENERATE AC response to Second GENERATE AC Not Requested. These bits shall be set in the second GENERATE AC response to the value of bits b8 – b7 of the Cryptogram Information Data returned in the response to the second GENERATE AC command of the current transaction (AAC or TC). This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

Application Cryptogram Type Returned in First GENERATE AC These bits shall be set in both the first and second GENERATE AC response to the value of bits b8 – b7 of the Cryptogram Information Data returned in the response to the first GENERATE AC command of the current transaction (AAC, TC, or ARQC). CDA Performed This bit shall be set in both the first and second GENERATE AC response if and only if Signed Dynamic Data is returned in the response to the GENERATE AC command of the current transaction. Offline DDA Performed This bit shall be set in both the first and second GENERATE AC response if and only if Signed Dynamic Application Data is returned in the response to the INTERNAL AUTHENTICATE command of the current transaction. Issuer Authentication Not Performed This bit shall be set in the second GENERATE AC response if and only if the CCDcompliant application did not receive Issuer Authentication Data. This may be the case if either the transaction was unable to go online or in the response message, the issuer did not provide Issuer Authentication Data. This bit shall be set in the first GENERATE AC response to the value this bit had in the most recent second GENERATE AC response sent by the CCD-compliant application. Issuer Authentication Failed This bit shall be set in the GENERATE AC response if and only if Issuer Authentication was performed and failed. In the first GENERATE AC response, it indicates Issuer Authentication failed in a previous online transaction. In the second GENERATE AC response, it indicates Issuer Authentication failed either in the current transaction, or in a previous transaction and the bit was not reset. Once set, this bit shall remain set until either:

  • Issuer Authentication is successful, or
  • all of the following conditions are true: - the transaction successfully went online (that is, the Authorisation Response Code does not indicate that the terminal was unable to go on-line) - Issuer Authentication was not performed - Issuer Authentication is not required by the CCD-compliant application for completion of an online transaction to be considered successful - Issuer Authentication is not required by the CCD-compliant application for resetting of non-velocity-checking indicators and counts. Low Order Nibble of PIN Try Counter These bits shall be set to the value of the low-order nibble (bits b4-b1) of the PIN Try Counter in both the first and second GENERATE AC response. Offline PIN Verification Performed This bit shall be set in both the first and second GENERATE AC response if and only if Offline PIN Verification has been performed (successfully or unsuccessfully) on the current transaction. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 Offline PIN Verification Performed and PIN Not Successfully Verified This bit shall be set in both the first and second GENERATE AC response if and only if Offline PIN Verification has been performed on the current transaction and the PIN was not successfully verified during processing of the current transaction. PIN Try Limit Exceeded This bit shall be set in both the first and second GENERATE AC response if and only if the PIN Try Counter is zero. Last Online Transaction Not Completed This bit shall be set in the first GENERATE AC response if and only if in the previous transaction, the CCD-compliant application requested to go online and the transaction was not completed (that is, the second GENERATE AC command was not received). Once set, this bit shall remain set until either:
  • Issuer Authentication is successful, or
  • all of the following conditions are true: - the transaction successfully went online (that is, the Authorisation Response Code does not indicate that the terminal was unable to go on-line) - Issuer Authentication was not performed - Issuer Authentication is not required by the CCD-compliant application for completion of an online transaction to be considered successful - Issuer Authentication is not required by the CCD-compliant application for resetting of non-velocity-checking indicators and counts. Lower Offline Transaction Count Limit Exceeded This bit shall be set in both the first and second GENERATE AC response if the CCDcompliant application has exceeded an issuer-specified lower limit for the number of transactions approved offline. This bit may represent the condition of multiple counters. At the least, all transactions approved offline whose amounts were not cumulated shall be included in at least one transaction count. This bit may also be set under additional conditions specified by the issuer. Upper Offline Transaction Count Limit Exceeded This bit shall be set in both the first and second GENERATE AC response if the CCDcompliant application has exceeded an issuer-specified upper limit for the number of transactions approved offline. This bit may represent the condition of multiple counters. At the least, all transactions approved offline whose amounts were not cumulated shall be included in at least one transaction count. This bit may also be set under additional conditions specified by the issuer. Lower Cumulative Offline Amount Limit Exceeded This bit shall be set in both the first and second GENERATE AC response if the CCDcompliant application has exceeded an issuer-specified lower limit for cumulative amounts approved offline. This bit may represent the condition of multiple counters. At the least, all domestic transactions approved offline shall be included in at least one cumulative amount. This bit may also be set under additional conditions specified by the issuer. Upper Cumulative Offline Amount Limit Exceeded This bit shall be set in both the first and second GENERATE AC response if the CCDcompliant application has exceeded an issuer-specified upper limit for cumulative amounts approved offline. This bit may represent the condition of multiple counters. At the least, all This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 domestic transactions approved offline shall be included in at least one cumulative amount. This bit may also be set under additional conditions specified by the issuer. Issuer-discretionary bit 1 – Issuer-discretionary bit 4: These bits are set in the first and second GENERATE AC response at the discretion of the issuer. The meaning of these bits is defined by the issuer and is outside the scope of this specification. Number of Issuer Script Commands Containing Secure Messaging Processed These bits shall be set in the first and second GENERATE AC response to the number of commands processed with secure messaging. Issuer Script Processing Failed This bit shall be set in both the first and second GENERATE AC response if and only if processing of a command with secure messaging failed. Once set, this bit shall remain set until either:
  • Issuer Authentication is successful, or
  • all of the following conditions are true: - the transaction successfully went online (that is, the Authorisation Response Code does not indicate that the terminal was unable to go on-line) - Issuer Authentication was not performed - Issuer Authentication is not required by the CCD-compliant application for completion of an online transaction to be considered successful - Issuer Authentication is not required by the CCD-compliant application for resetting of non-velocity-checking indicators and counts. Offline Data Authentication Failed on Previous Transaction This bit shall be set in both the first and second GENERATE AC response if and only if, in the Terminal Verification Results (TVR) returned during the previous transaction, any of the following bits was set:
  • Offline Static Data Authentication Failed
  • Offline Dynamic Data Authentication Failed
  • Combined DDA/AC Generation Failed Once set, this bit shall remain set until a transaction either successfully went online or was approved offline. Go Online on Next Transaction Was Set This bit shall be set in both the first and second GENERATE AC response if and only if the Set Go Online On Next Transaction bit of the last successfully recovered CSU was set, or it is a new card and the issuer has specified that a new card is required to set the Go Online on Next Transaction bit. Once set, this bit shall remain set until either:
  • Issuer Authentication is successful, or
  • all of the following conditions are true: This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 - the transaction successfully went online (that is, the Authorisation Response Code does not indicate that the terminal was unable to go on-line) - Issuer Authentication was not performed - Issuer Authentication is not required by the CCD-compliant application for completion of an online transaction to be considered successful - Issuer Authentication is not required by the CCD-compliant application for resetting of non-velocity-checking indicators and counts. Unable to go Online This bit shall be set in the second GENERATE AC response if and only if the Authorization Response Code, tag '8A', returned from the terminal indicates the terminal was unable to go online (set to 'Y3' or 'Z3').

5.2.3.3 Mandatory Actions Due to CVR Bit Settings The following is a list of mandatory actions that shall be taken by the CCD-compliant application, and issuer-configurable options that shall be supported by the CCD-compliant application. Issuer Authentication Not Performed The issuer shall have the option to specify that if this bit is set, the CCD-compliant application shall force transactions at online-capable terminals to go online. The issuer shall have the option to specify that if this bit is set, and either it is an offline-only terminal or the terminal is unable to go online, whether the CCD-compliant application shall:

  • accept the transaction, or
  • decline the transaction. Issuer Authentication Failed The issuer shall have the option to specify that if this bit is set, the CCD-compliant application shall force transactions at online-capable terminals to go online. The issuer shall have the option to specify that if this bit is set, and either it is an offline-only terminal or the terminal is unable to go online, whether the CCD-compliant application shall:
  • accept the transaction, or
  • decline the transaction. PIN Try Limit Exceeded The issuer shall have the option to specify that if this bit is set, the CCD-compliant application shall decline the transaction offline. The issuer shall have the option to specify that if this bit is set, the CCD-compliant application shall force transactions at online-capable terminals to go online. The issuer shall have the option to specify that if this bit is set, and either it is an offline-only terminal or the terminal is unable to go online, whether the CCD-compliant application shall:
  • accept the transaction, or
  • decline the transaction. The ICC shall not block the application due to this bit being set. The ICC shall not block the card due to this bit being set. Last Online Transaction Not Completed If this bit is set, the CCD-compliant application shall force the transactions at online-capable terminals to go online. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 The issuer shall have the option to specify that if this bit is set, and either it is an offline-only terminal or the terminal is unable to go online, whether the CCD-compliant application shall:
  • accept the transaction, or
  • decline the transaction. Lower Offline Transaction Count Limit Exceeded If this bit is set in the first GENERATE AC response, the CCD-compliant application shall force the transaction at online-capable terminals to go online. Upper Offline Transaction Count Limit Exceeded If this bit is set and either it is an offline-only terminal or the terminal is unable to go online, the CCD-compliant application shall decline the transaction. However, the issuer shall have the option to allow the CCD-compliant application to override this decline for a transaction at Terminal Type 26. Lower Cumulative Offline Amount Limit Exceeded If this bit is set in the first GENERATE AC response, the CCD-compliant application shall force the transaction at online-capable terminals to go online. Upper Cumulative Offline Amount Limit Exceeded If this bit is set and either it is an offline-only terminal or the terminal is unable to go online, the CCD-compliant application shall decline the transaction. However, the issuer shall have the option to allow the CCD-compliant application to override this decline for a transaction at Terminal Type 26. Issuer Script Processing Failed The issuer shall have the option to specify that if this bit is set, the CCD-compliant application shall force transactions at online-capable terminals to go online. Go Online on Next Transaction Was Set The issuer shall have the option to specify that if this bit is set, and either it is an offline-only terminal or the terminal is unable to go online, whether the CCD-compliant application shall:
  • accept the transaction, or
  • decline the transaction.

5.3 Command Use The ICC shall respond to the first GENERATE AC with any of the following cryptogram types:

  • TC
  • ARQC
  • AAC The ICC shall not respond to the first GENERATE AC command with an AAR. The ICC shall respond to the second GENERATE AC (if applicable) with either of the following cryptogram types:
  • TC
  • AAC This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

5.3.1 GENERATE AC (First Issuance) The ICC shall not respond with an AAR.

6.5 Cardholder Verification The CCD-compliant application shall support Cardholder Verification. It shall indicate this by setting the Application Interchange Profile Byte 1, bit 5 = '1'.

6.6.3 Velocity Checking The CCD-compliant application shall not request the terminal to perform velocity checking. The CCD-compliant application shall not deliver the Lower Consecutive Offline Limit (Tag '9F14') and Upper Consecutive Offline Limit (Tag '9F23') data elements to the terminal.

6.8 Card Action analysis The ICC shall not request a referral

The ICC will not request that the terminal send an advice message to the issuer.

6.8.1 Terminal Messages for an AAC The CCD-compliant application shall set the Cryptogram Information Data bits b3-b1 of the CID to '000' in the GENERATE AC command response.

6.8.3 Advice Messages The CCD-compliant application shall not request the terminal to send an advice message. Bit b4 of the Cryptogram Information Data shall be set to ‘0’.

6.10 Issuer-to-Card Script Processing An issuer shall send no more than one issuer script template in an authorization response message. The script template may contain multiple commands. The script template may be Tag ‘71’ or Tag ‘72’. The following Section 6.11.1 applies to a CCD-compliant application.

6.11.1 Additional Completion Actions for a CCD-Compliant Application 6.11.1.1 Actions Taken by a CCD-Compliant Application After Issuer Authentication is Successful After Issuer Authentication is successful, if the CSU Created by Proxy for the Issuer bit is set to '1' in the CSU, and the Issuer specifies that Update Counters shall not be used, the following shall govern the behaviour of velocity-checking counters and cumulative amounts associated with the offline transaction limits referred to in bits b8-b5 of Byte 3 of the CVR: This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

  • If the Issuer specifies that the application shall not update the offline counters, no offline counter or cumulative amount is modified.
  • If the Issuer specifies that the application shall set the offline counters to zero, the application will reset all the offline counters and cumulative amounts to zero. By doing so, the issuer allows the application to accept offline transactions, up to the offline limits.
  • If the Issuer specifies that the application shall set the offline counters to the upper offline limits, the offline counters and cumulative amounts will be set to their respective upper limits.
  • If the Issuer specifies that the application shall add the transaction to the offline counter(s), the transaction will be included in the offline counters or cumulative amounts as if it were an offline transaction. The following describes the actions to be taken by the CCD-compliant application due to the setting of each bit in the CSU after Issuer Authentication is successful. Issuer Approves Online Transaction If Issuer Approves Online Transaction is set and the terminal requests a TC, the application shall approve the transaction by returning a TC. If Issuer Approves Online Transaction is not set, the application shall decline the transaction by returning an AAC. Card Block If Card Block is set, all applications in the ICC shall be permanently disabled, including applications that may be selected implicitly. For all subsequent SELECT commands the card shall return the status bytes ‘Function not supported’ (SW1-SW2 = ‘6A81’) and perform no other action. Application Block If Application Block is set, the currently selected application shall be invalidated. An invalidated application shall return the status bytes ‘Selected file invalidated’ (SW1-SW2 = ‘6283’) in response to a SELECT command and return only an AAC in response to the GENERATE AC command. Update PIN Try Counter If Update PIN Try Counter is set, the application shall update the PIN Try Counter (PTC) with the value contained in bits b4-b1 of Byte 1 of the CSU. If the PIN is blocked, updating the value of the PTC with a non-zero value unblocks the PIN. Updating the value of the PTC with a zero value blocks the PIN. If Update PIN Try Counter is not set, no update of the PTC shall be performed by the application. The value contained in the bits b4-b1 of Byte 1 of the CSU shall never be interpreted by the application. Set Go Online on Next Transaction If Set Go Online on Next Transaction is set, the application shall force subsequent transactions at online-capable terminals to go online (that is, the CCD-compliant application shall return an ARQC in response to the first GENERATE AC command if a TC or an ARQC is requested). The application shall continue to try to go online at online-capable terminals until either Issuer Authentication is successful, or the transaction successfully went online and Issuer Authentication was not required by the Issuer for completion of an online transaction to be considered successful. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 Update Counters Update Counters (bits b2-b1 of Byte 2 of the CSU) govern the behaviour of velocity-checking counters and cumulative amounts associated with the offline transaction limits referred to in bits b8-b5 of Byte 3 of the CVR if either of the following is true:
  • the CSU Created by Proxy for the Issuer bit is set to '0' in the CSU
  • the Issuer specifies that the application shall use the Update Counters bits in the CSU to update the velocity-checking count(s) and cumulative amount(s) regardless of the bit setting for CSU Created by Proxy for the Issuer. If Update Counters is set to Do Not Update Offline Counters, no offline counter or cumulative amount is modified. If Update Counters is set to Reset Offline Counters to Zero, the application will reset all the offline counters and cumulative amounts to zero. By doing so, the issuer allows the application to accept offline transactions, up to the offline limits. If Update Counters is set to Set Offline Counters to Upper Offline Limits, the offline counters and cumulative amounts will be set to their respective upper limits. If Update Counters is set to Add Transaction to Offline Counters, the transaction will be included in the offline counters or cumulative amounts as if it were an offline transaction.

6.11.1.2 Other Completion Actions After the transaction successfully went online (that is, the Authorisation Response Code does not indicate that the terminal was unable to go on-line), the CCD-compliant application shall reset to zero the count of script commands processed with secure messaging if either of the following conditions is true:

  • Issuer Authentication is successful, or
  • all of the following conditions are true: - Issuer Authentication was not performed - Issuer Authentication is not required by the CCD-compliant application for completion of an online transaction to be considered successful - Issuer Authentication is not required by the CCD-compliant application for resetting of non-velocity checking indicators and counts. After the transaction successfully went online (that is, the Authorisation Response Code does not indicate that the terminal was unable to go on-line), the CCD-compliant application shall reset to zero the velocity-checking offline transaction count(s) and cumulative offline amount(s) if all of the following are true:
  • The terminal requested a TC
  • Issuer Authentication was not performed
  • Issuer Authentication is not required by the CCD-compliant application for completion of an online transaction to be considered successful
  • Issuer Authentication is not required by the CCD-compliant application to reset the velocity-checking counters. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 After the transaction successfully went online (that is, the Authorisation Response Code does not indicate that the terminal was unable to go on-line), the CCD-compliant application shall approve the transaction if all of the following conditions are true:
  • the terminal requested a TC, and
  • one of the following is true: - Issuer Authentication Passed and the Issuer Approves Online Transaction bit of the recovered CSU is set to '1', or - Issuer Authentication was not performed and Issuer Authentication is not required by the CCD-compliant application for completion of an online transaction to be considered successful. If Issuer Authentication was performed and failed, the CCD-compliant application shall decline the transaction. Annex A - Data Elements Table The data elements shown in Table CCD – 6 with a source of:
  • ‘Terminal’ shall not be included in any DOL used by a CCD-compliant application.
  • ‘ICC’ shall not be identified in the AFL of a CCD-compliant application. Data Element Name Amount Reference Currency Application Reference Currency Application Reference Currency Exponent Default Dynamic Data Authentication Data Object List (DDOL) Transaction Certificate (TC) Hash Value Lower Consecutive Offline Limit Upper Consecutive Offline Limit Tag '9F3A' ‘9F3B’ ‘9F43’ -‘98’ '9F14' '9F23' Source Terminal ICC ICC Terminal Terminal ICC ICC Table CCD – 6 Data Elements Not Used by a CCD-Compliant Application This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 The following additional data elements for Table A-1 are defined within the context of the Common Core Definitions. Name

Description

Card Contains data sent to the issuer indicating Verification exception conditions that occurred during Results (CVR) the current and previous transactions. Transmitted to the terminal in Issuer Application Data as specified in Annex C.8.2 Table CCD – 9. Common Core Data sent to the issuer identifying the Identifier (CCI) format of the Issuer Application Data and the method for calculating the Application Cryptogram. Transmitted to the terminal in Issuer Application Data as specified in Annex C.8.2 Table CCD – 9. Contains the following: Format Code (FC) Cryptogram Version (CV) Derivation Key Data sent to the issuer identifying the Index (DKI) issuer’s derivation key for deriving the card’s ICC Master Keys. Transmitted to the terminal in Issuer Application Data as specified in Annex C.8.2 Table CCD – 9. Issuer Contains issuer proprietary application Discretionary data for transmission to the issuer in an Data online transaction. Transmitted to the terminal in Issuer Application Data as specified in Annex C.8.2 Table CCD – 9. Source Format ICC b ICC b ICC b ICC b Template --- --- Tag Length -- 5 -- 1 -- 1 -- 15 Table CCD – 7 Additional Data Elements Defined for Table A-1 C.7 – Transaction Log Information If the CCD-compliant application supports transaction logging, it shall support transaction logging using the method specified in section C.7. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004

Please add the following sections after Annex C.7. C.8 – Issuer Application Data for a Common Core Definitions-Compliant Application The CCD-compliant application shall have an Issuer Application Data field of fixed length, 32-bytes long with the following attributes:

  • Byte 1 shall be set to '0F'.
  • Byte 2 shall be the Common Core Identifier (CCI).
  • Byte 17 shall be set to '0F'. C.8.1 Common Core Identifier The CCI shall identify the format of the Issuer Application Data field, and the Cryptogram Version. Values in the range '00' to '9F' are reserved to avoid conflict with legacy Cryptogram Version Numbers. b8 b7 b6 b5 b4 b3 b2 b1 Meaning x x x x Common Core Issuer Application Data Format Code (FC). 1 0 1 0 CCD Version 4.1 Issuer Application Data Format (= ‘A’) x x x x Common Core Cryptogram Version (CV) 0 1 0 0 CCD Version 4.1 Cryptogram Version (= ‘4’) Table CCD – 8 - Common Core Identifier Bits b8 - b5 of the CCI shall indicate the Format Code (FC). Values in the range 'A' - 'F' shall indicate a CCD-specified Issuer Application Data format (all values RFU by EMVCo for CCD). Bits b4 - b1 of the CCI shall indicate the Cryptogram Version (CV) for the Application Cryptogram. It indicates the cryptogram input data, and key derivation method the CCDcompliant application uses to generate the Application Cryptogram; and the cryptogram input data (including CSU coding), key derivation method, and method the CCD-compliant application expects the Issuer to use when generating the Authorisation Response Cryptogram. Values in the range '4' - 'F' shall indicate a CCD-specified cryptogram algorithm and data set (all values RFU by EMVCo for CCD). Values in the range '0' - '3' shall indicate a proprietary cryptogram algorithm. Applications, when using the CV range '0' - '3', are not CCD-compliant. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 C.8.2 Issuer Application Data lay-out for Format Code ‘A’ The format and coding of the Issuer Application Data field with a Format Code of 'A' shall be as shown in Table CCD – 9: Byte(s) Contents 1 Length Indicator 2 CCI 3 DKI 4-8 CVR 9-16 Counters 17 Length Indicator 18-32 Issuer Discretionary Data Description Length of EMVCo-defined data in IAD. Set to '0F' Common Core Identifier Derivation Key Index Card Verification Results (see section C.8.3) Contents are at the discretion of the Payment System. Length of Issuer Discretionary Data field in IAD. Set to '0F'. Contents are at the discretion of the issuer. Table CCD – 9 - Issuer Application Data C.8.3 Card Verification Results The coding of the CVR for a Common Core Issuer Application Data Format Code of value 'A' shall be as shown in Table CCD – 10. CVR Byte 1 b8 b7 b6 b5 b4 b3 b2 b1 Meaning x x Application Cryptogram Type Returned in Second GENERATE AC 0 0 AAC 0 1 TC 1 0 Second GENERATE AC Not Requested 1 1 RFU x x Application Cryptogram Type Returned in First GENERATE AC 0 0 AAC 0 1 TC 1 0 ARQC 1 1 RFU 1 CDA Performed 1 Offline DDA Performed 1 Issuer Authentication Not Performed 1 Issuer Authentication Failed CVR Byte 2 b8 b7 b6 b5 b4 b3 b2 b1 Meaning x x x x Low Order Nibble of PIN Try Counter 1 Offline PIN Verification Performed 1 Offline PIN Verification Performed and PIN Not Successfully Verified 1 PIN Try Limit Exceeded 1 Last Online Transaction Not Completed This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 CVR Byte 3 b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 Lower Offline Transaction Count Limit Exceeded 1 Upper Offline Transaction Count Limit Exceeded 1 Lower Cumulative Offline Amount Limit Exceeded 1 Upper Cumulative Offline Amount Limit Exceeded 1 Issuer-discretionary bit 1 1 Issuer-discretionary bit 2 1 Issuer-discretionary bit 3 1 Issuer-discretionary bit 4 CVR Byte 4 b8 b7 b6 b5 b4 b3 b2 b1 Meaning xxxx Number of Issuer Script Commands Containing Secure Messaging Processed 1 Issuer Script Processing Failed 1 Offline Data Authentication Failed on Previous Transaction 1 Go Online on Next Transaction Was Set 1 Unable to go Online CVR Byte 5 b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 0 0 0 0 0 0 RFU Table CCD – 10 - Card Verification Results for Format Code 'A' C.9 – Card Status Update for a Common Core DefinitionsCompliant Application The Issuer Authentication Data shall include a Card Status Update (CSU) of fixed length, 4bytes long. The coding of the CSU is shown in Table CCD – 11. CSU Byte 1 b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 0 0 RFU x x x x PIN Try Counter CSU Byte 2 b8 b7 b6 b5 b4 b3 b2 b1 1 1 1 1 1 1 x x 0 0 1 0 0 1 1 1 Meaning Issuer Approves Online Transaction Card Block Application Block Update PIN Try Counter Set Go Online on Next Transaction CSU Created by Proxy for the Issuer Update Counters Do Not Update Offline Counters Reset Offline Counters to Zero Set Offline Counters to Upper Offline Limits Add Transaction to Offline Counter This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 CSU Byte 3 b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 0 0 0 0 0 0 RFU CSU Byte 4 b8 b7 b6 b5 b4 b3 b2 b1 Meaning x x x x x x x x Issuer-Discretionary Table CCD – 11 - Card Status Update for Cryptogram Version '4' The CSU Created by Proxy for the Issuer bit shall be set in the CSU if and only if the CSU is generated by a proxy for the Issuer. This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 In review of comments on Draft Specification Update Bulletin 25, the CCD modifications to Book 3 section 6.2 were determined to be of general significance and were thus moved to the body of the EMV specification. Please make the following changes to EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 3 Add the following text as a footnote to Book 3 section 6.2 Read Application Data. The footnote should be attached to the end of the fourth paragraph under the 'Description' heading. 'Payment system-specific tags are interpreted within the context of the application RID. Issuer-specific tags are interpreted within the context of the Issuer Identification Number (as defined in ISO/IEC 7812-1). Additionally, to satisfy business requirements such as proprietary domestic processing, multiple Issuers may agree on the definition of a private class tag. Such tags may be interpreted in the context of other data such as Issuer Country Code.' This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004 In review of comments on Draft Specification Update Bulletin 25, the CCD modifications to Book 4 were determined to be of general significance and were thus moved to the body of the EMV specification. Please make the following changes to EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 4. Please make the following changes to the Cryptogram Information Data row of Table 1 in section 8.1.1, Authorisation Request: In the Data Element column, delete the "*" after "Cryptogram Information Data". Add the following text to the Condition column, "The Cryptogram Information Data does not need to be forwarded to the issuer, the presence of this data element is defined in the respective Payment System network interface specifications". Please make the following changes to the Cryptogram Information Data row of Table 3 in section 8.1.2, Financial Transaction Request: In the Data Element column, delete the "*" after "Cryptogram Information Data". Add the following text to the Condition column, "The Cryptogram Information Data does not need to be forwarded to the issuer, the presence of this data element is defined in the respective Payment System network interface specifications". Please make the following changes to the Cryptogram Information Data row of Table 9 in section 8.1.5, Batch Data Capture: In the Data Element column, delete the "*" after "Cryptogram Information Data". Add the following text to the Condition column, "The Cryptogram Information Data does not need to be forwarded to the issuer, the presence of this data element is defined in the respective Payment System network interface specifications". This document contains proprietary and confidential information of EMVCo LLC. Copyright © EMVCo LLC 2004