PCI Watch

Tracking changes across the Payment Card Industry

SB nº SU-41: Corrections to Common Core Definitions (Spec Change)

v3.0 Specification Bulletins

Specification Update Bulletin No. 41 Third Edition November 2007 Corrections to Common Core

Definitions

This Specification Update Bulletin describes changes to the EMV Integrated Circuit Card Specifications for Payment Systems. This edition of the bulletin is effective 1 November 2007. Changes in this edition of the bulletin will be incorporated into version 4.1c of the CCD Card Type Approval documentation (that is, Test Cases, Card Images, and Implementation Conformance Statement); and into version 1.0c of the CPA Card Type Approval documentation. Testing is effective 1 February 2008. This bulletin is mandatory for all CCD cards.

Applicability

This Specification Update Bulletin applies to:

  • EMV Integrated Circuit Card Specifications for Payment Systems Version 4.1 Book 3

Related Documents

None

Description

This bulletin addresses issues with the Common Core Definitions found during development of the CCD test requirements and the Common Payment Application specification. In some instances, multiple issues affect the same section of text. Thus, the following descriptions explain the reasons for the proposed changes to the CCD specifications. The proposed specification changes for all the issues are combined in the section, Proposed Specification Change Notice. Changes from the previous edition of this bulletin are marked in the left margin. New Issuer Authentication Behaviour CCD requires an application to decline a transaction if issuer authentication is performed and fails. Historically, issuer authentication failure is not uncommon when an issuer is beginning to implement full chip data support. While the current CCD allows the issuer to work around this problem by not sending the Issuer Authentication Data to a CCD-compliant card, we have determined that CCD

should include an option that allows the issuer to indicate whether the application should require issuer authentication to pass in order to approve a transaction where issuer authentication is performed. If successful issuer authentication is required to approve the transaction, the application will continue to decline a transaction when issuer authentication is performed and fails, as currently specified in CCD. The new option impacts the description of behaviour for the condition where Issuer Authentication Data is received by the application, and issuer authentication fails. If issuer authentication fails, the CSU cannot be relied upon to indicate the issuer’s choice for whether to approve or decline the transaction. The type of Application Cryptogram requested by the terminal in the GENERATE AC command is used to determine whether to approve or decline a transaction when issuer authentication fails and the issuer does not require issuer authentication to pass when performed. The addition of the new option makes ambiguous the descriptions for the two options (in section 9.2.3.1 of EMV 4.1, Book 3, Part CCD) that reset card risk management amounts, counts and indicators. “Issuer Authentication is required” could mean either that it is required to be performed, or that it is required to pass if it is performed. The use of the two options is clarified. The conditions for resetting non-velocity-checking counts and indicators are updated. The conditions for resetting velocity-checking offline transaction count(s) and cumulative offline amount(s) are also updated. Decline for Issuer Authentication Not Performed Option The description of the behaviour associated with the issuer option that requires issuer authentication to be performed for an online transaction to be considered successful is incomplete. CCD only describes the behaviour when the option is satisfied. The clarification that the transaction must be declined when the option is not satisfied is added. Issuer Script Command Processing The requirement in CCD to reset indicators in the CVR that are related to the processing of Issuer script commands does not work properly for script commands received before the second GENERATE AC command. The issuer may not receive indication of the failure of tag ‘71’ issuer script commands if the conditions to reset the CVR indicators are met during processing of the second GENERATE AC. This can be resolved by clarifying that the bit is reset on a subsequent transaction where the conditions to reset are met. Furthermore, the requirement to reset the count of script commands processed can lead to ambiguity in interpreting the count of script commands processed. Consider the situation where processing of one of a series of commands in a single script fails. The issuer attempts to send the script again, and again receives indication that a script failed with the same count indicated. The issuer is unable to determine whether the card never received the commands from the reset script, or whether the script keeps failing on the same command. By eliminating the requirement to reset the count of script commands, the ambiguity is removed, while allowing implementations that have found a solution to this ambiguity using the Issuer-Discretionary portions of the CVR and Issuer Application Data elements to still meet the CCD Specification. The definition of the Number of Issuer Script Commands Containing Secure Messaging Processed has been clarified to count only successfully processed script commands. By counting only successfully processed script commands the issuer knows which updates have been done in the card and which were not when script commands fail. The bit is renamed as "Number of Successfully Processed Issuer Script Commands Containing Secure Messaging" to reflect this change.

Offline Data Authentication Failed on Previous Transaction and Go Online in Next Transaction Was Set CVR Bits The requirement in CCD for resetting the Offline Data Authentication Failed on Previous Transaction and the Go Online in Next Transaction Was Set CVR bits could clear the bits before they are sent to the issuer. This is caused by ambiguous wording in the reset conditions. The issuer might not receive indication of the Offline Data Authentication Failed on Previous Transaction if the subsequent transaction were approved offline at the first GENERATE AC command. The issuer also might not receive indication that the Go Online On Next Transaction bit in the CSU was set if an implementer cleared the CVR indicator during processing of the second GENERATE AC because issuer authentication had passed. These ambiguities can be resolved by clarifying that the bits are reset on a subsequent GENERATE AC command where the conditions to reset are met. Thus, at least one authorization or offline clearing message will be sent to the issuer with a CVR indicating the event has occurred. The modified wording for the Go Online in Next Transaction Was Set bit also clarifies that if the Set Go Online on Next Transaction bit is set in the CSU recovered during a successful issuer authentication, the CVR bit is not reset. Support for Offline PIN Verification Capability The ability for the card to support offline PIN is implied by several requirements in CCD, but is not stated explicitly. A CCD-compliant application shall, as a minimum, be capable of supporting offline plaintext PIN verification as a possible method for cardholder verification. It is the issuer’s choice at personalization whether or not to specify a Cardholder Verification Rule that includes ‘Plaintext PIN verification performed by the ICC’. Authorisation Response Code in CDOL2 CCD includes an implied requirement that tag ‘8A’ (Authorisation Response Code) be included in CDOL2 in order for the CCD-compliant application to identify when the terminal is unable to go online. This is made clear by stating the requirement. Addition of different Issuer Application Data The Issuer Application Data defined in CCD conflicts with requirements for cardholder convenience when the application is used as an authentication token generator. On special devices the compliance with the CCD Issuer Application Data is relaxed to allow for different content. Tag for TC Hash Value The tag value shown for a reference to the TC Hash Value was incorrect. The correct value is given. Clarification of Options in Mandatory Actions When CVR Bits are Set

The options in section 9.2.3.3 of EMV 4.1, Book 3, Part CCD, that indicate that the application shall accept the transaction could conflict with other card risk management options that might indicate the application must be declined. The wording is clarified to indicate that the option is to allow the application to approve the transaction. The options in section 9.2.3.3 of EMV 4.1, Book 3, Part CCD, that indicate the application shall force transactions at online-capable terminals to go online do not identify the alternative for when the bit is not set. The wording is clarified to indicate that the alternative is to allow the transaction to remain offline. Proposed Specification Change Notice Please make the following changes to EMV Integrated Circuit Card Specifications for Payment Systems Version 4.1 Book 3, Part V. Change the first sentence of Section 6.5.5.3, from: “CDOL2 shall include tag ‘91’ (Issuer Authentication Data).” to: “CDOL2 shall include tag ‘8A’ (Authorisation Response Code) and tag ‘91’ (Issuer Authentication Data).” Add a new section as follows: “6.5.12.2 Command Message To allow an issuer to use offline plaintext PIN verification as a possible CVM, a CCD-compliant card shall support the VERIFY command with parameter P2 = ‘80’ as defined in Book 3, Table 23.” Change the “tag ‘97’ ” in Section 9.2.2, to “tag ‘98’ ”. Replace1 all but the last two paragraphs and last four bullets of Section 9.2.3.1 with the following: “The issuer shall have the option of specifying whether a new card is required to set the ‘Go Online on Next Transaction Was Set’ bit. The issuer shall have the option of specifying whether the CCD-compliant application requires issuer authentication to be performed for the application to approve (TC) an online transaction. The issuer shall have the option of specifying whether the CCD-compliant application requires issuer authentication to pass when performed for the application to approve (TC) an online transaction. If the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction, the issuer shall have the option 1 For clarity, the replacement text incorporates all the individual edits to section 9.2.3.1 from previous versions of this bulletin.

of specifying whether the CCD-compliant application requires issuer authentication to pass for resetting 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 the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction, the issuer shall have the option of specifying whether the CCD-compliant application requires issuer authentication to pass for resetting all the following non-velocity checking indicators:
  • Last Online Transaction Not Completed
  • Issuer Script Processing Failed
  • Go Online on Next Transaction Was Set If the CCD-compliant application does not require issuer authentication to be performed or does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction, the issuer shall have the option of specifying whether the CCD-compliant application requires issuer authentication to pass for resetting the velocity checking offline transaction count(s) and cumulative amount(s).” In Section 9.2.3.2, Setting and Resetting of Bits in the CVR; under the description for the Issuer Authentication Failed bit in the CVR; change: “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 online), ƒ issuer authentication was not performed, ƒ the CCD-compliant application does not require issuer authentication for completion of an online transaction to be considered successful, and ƒ the CCD-compliant application does not require issuer authentication for resetting of non-velocity-checking indicators and counts.” to: “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 online), ƒ issuer authentication was not performed, ƒ the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.” In Section 9.2.3.2, Setting and Resetting of Bits in the CVR; under the description for the Last Online Transaction not Completed bit in the CVR; change: “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 online), ƒ issuer authentication was not performed, ƒ the CCD-compliant application does not require issuer authentication for completion of an online transaction to be considered successful, and ƒ the CCD-compliant application does not require issuer authentication for resetting of non-velocity-checking indicators and counts.” to: “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 online), ƒ issuer authentication was not performed, ƒ the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.”
  • 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 online), ƒ issuer authentication was performed and failed, ƒ the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.” In Section 9.2.3.2, Setting and Resetting of Bits in the CVR; change the descriptions for the Number of Issuer Script Commands Containing Secure Messaging Processed to: “Number of Successfully Processed Issuer Script Commands Containing Secure Messaging In the first and second GENERATE AC response, these bits shall be set to the number of commands successfully processed with secure messaging.” In Section 9.2.3.2, Setting and Resetting of Bits in the CVR; under the descriptions for the Issuer Script Processing Failed bit in the CVR; change: “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 online), ƒ issuer authentication was not performed, ƒ the CCD-compliant application does not require issuer authentication for completion of an online transaction to be considered successful, and ƒ the CCD-compliant application does not require issuer authentication for resetting of non-velocity-checking indicators and counts.” to: “Once set, this bit shall remain set until a subsequent GENERATE AC command where 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 online), ƒ issuer authentication was not performed, ƒ the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.”
  • 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 online), ƒ issuer authentication was performed and failed, ƒ the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.” In Section 9.2.3.2, Setting and Resetting of Bits in the CVR, under the description for the Offline Data Authentication Failed on Previous Transaction bit in the CVR; change: “Once set, this bit shall remain set until a transaction either successfully went online or was approved offline.” to: “Once set, this bit shall remain set until a subsequent transaction is performed that meets either of the following conditions:
  • the previous transaction successfully went online, or
  • the previous transaction was approved offline. If either condition is met the bit is reset in the first GENERATE AC response.” In Section 9.2.3.2, Setting and Resetting of Bits in the CVR; under the descriptions for the Go Online On Next Transaction Was Set bit in the CVR; change: “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 online), ƒ issuer authentication was not performed, ƒ the CCD-compliant application does not require issuer authentication for completion of an online transaction to be considered successful, and ƒ the CCD-compliant application does not require issuer authentication for resetting of non-velocity-checking indicators and counts.” to: “Once set, this bit shall remain set until a subsequent GENERATE AC command where either:
  • all of the following conditions are true: ƒ issuer authentication is successful, and ƒ the Set Go Online on Next Transaction bit of the CSU is not set.
  • 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 online), ƒ issuer authentication was not performed, ƒ the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.”
  • 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 online), ƒ issuer authentication was performed and failed, ƒ the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.” In Section 9.2.3.3, Mandatory Actions Due to CVR Bit Settings; under the descriptions for the actions associated with the CVR bits Issuer Authentication Not Performed, Issuer Authentication Failed, PIN Try Limit Exceeded, Last Online Transaction Not Completed, and Go Online On Next Transaction Was Set; change:
  • “accept the transaction, or” to:
  • “be allowed to approve (TC) the transaction, or” In Section 9.2.3.3, Mandatory Actions Due to CVR Bit Settings; under the descriptions for the actions associated with the CVR bits Issuer Authentication Not Performed, Issuer Authentication Failed, PIN Try Limit Exceeded, Last Online Transaction Not Completed, Issuer Script Processing Failed, and Go Online On Next Transaction Was Set; change: “The issuer shall have the option of specifying that if this bit is set, the CCD-compliant application shall force transactions at online-capable terminals to go online.” to: “The issuer shall have the option of specifying that if this bit is set, whether the CCD-compliant application shall:
  • force transactions at online-capable terminals to go online, or
  • allow the transaction to remain offline.” Add a new section as follows: “10.5.1 Offline PIN Processing The CCD-compliant application shall be capable of supporting offline plaintext PIN verification. It is the Issuer’s option whether or not to use offline plaintext PIN as a cardholder verification method.” In section 10.11.1.1, under the description for the Set Go Online on Next Transaction bit, change the last sentence to: “The application shall continue to try to go online at online-cable terminals until a subsequent GENERATE AC command where either:
  • all of the following conditions are true: ƒ issuer authentication is successful, and ƒ the Set Go Online on Next Transaction bit of the CSU is not set.
  • 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 online), ƒ issuer authentication was not performed, ƒ the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.”
  • 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 online), ƒ issuer authentication was performed and failed, ƒ the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of non-velocity-checking indicators.” Replace all of Section 10.11.1.2 with the following: “After the transaction successfully went online (that is, the Authorisation Response Code does not indicate that the terminal was unable to go online), the CCD-compliant application shall reset to zero the velocity-checking offline transaction count(s) and cumulative offline amount(s) if either of the following are true:
  • all of the following conditions are true: ƒ the terminal requested a TC, ƒ issuer authentication was not performed, ƒ the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of velocity-checking counters.”
  • or all of the following conditions are true: ƒ the terminal requested a TC, ƒ issuer authentication was performed and failed, ƒ the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction, and ƒ the CCD-compliant application does not require issuer authentication to pass for resetting of velocity-checking counters. After the transaction successfully went online (that is, the Authorisation Response Code does not indicate that the terminal was unable to go online), 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 is successful and the ‘Issuer Approves Online Transaction bit’ of the recovered CSU is set to 1, or ƒ issuer authentication was not performed and the CCD-compliant application does not require issuer authentication to be performed for the application to approve (TC) an online transaction, or ƒ issuer authentication was performed and failed and the CCD-compliant application does not require issuer authentication to pass when performed for the application to approve (TC) an online transaction. After the transaction successfully went online (that is, the Authorisation Response Code does not indicate that the terminal was unable to go online), the CCD-compliant application shall decline the transaction in the second GENERATE AC response if either of the following conditions are true:
  • both of the following are true: ƒ issuer authentication was not performed, and ƒ the CCD-compliant application requires issuer authentication to be performed for the application to approve (TC) an online transaction,
  • or both of the following are true: ƒ issuer authentication was performed and failed, and ƒ the CCD-compliant application requires issuer authentication to pass when performed for the application to approve (TC) an online transaction, After the transaction did not successfully complete online (that is the Authorisation Response Code indicates that the terminal was unable to go online), the CCD-compliant application shall decide whether to approve or decline the transaction.” After the first paragraph in Annex C section C7 add the following paragraph: “The CCD-compliant application shall support the selection of different Issuer Application Data if:
  • the card requests the Terminal Type and the Additional Terminal Capabilities in PDOL, and
  • the values provided by the terminal in the PDOL related data for the Terminal Type and the first two bytes of the Additional Terminal Capabilities are '34’ and '0000' respectively” In section C7.3 change the description in the CVR Byte 4 bits b8 to b5 to: “Number of Successfully Processed Issuer Script Commands Containing Secure Messaging”