6.10 Issuer scripts

It was mentioned in Section 6.9.1 that the authorization response message 1110 received from the IH can include post-issuance commands to be delivered to the ICC via the terminal. These commands are not relevant for the current EMV ¢ transaction, but they are used for updating the application data in the card during its utilization lifetime, or for switching an application in the card or even the entire card between the "unblocked" and "blocked" states. EMV ¢ does not make any provisions for updating the application code in the card. The format of the post-issuance commands can be proprietary to the issuer. They are not meaningful for the terminal, which should only dispatch them from the authorization response message and send them sequentially to the ICC that has to be updated.

6.10.1 Processing of issuer script templates

The IH can group the post-issuance commands in two types of templates:

Issuer Script Template 1 (tag 71) groups proprietary post-issuance commands to be transmitted to the ICC before sending the 2nd GENERATE AC to the ICC.
Issuer Script Template 2 (tag 72) groups proprietary post-issuance commands to be transmitted to the ICC after sending the second GENERATE AC to the ICC.

Each issuer script template, regardless of whether it is of the type 1 or type 2, can include the following data objects:

Issuer Script Identifier (tag 9F18), which is represented on 4 bytes in binary format. This identifier is optional and is not interpreted by the terminal. The Issuer Script Identifier allows the issuer to distinguish among several issuer script templates that can be included in the same authorization response message.
Issuer Script Command APDU (tag 86) has a variable number of bytes depending on the type of the C-APDU to be sent to the card. Several Issuer Script Command APDU(s) can be included in an issuer script template.

The issuer can send more than one issuer script template in the same authorization response message. The only restriction is that the total length of the issuer script templates is less than or equal to 128 bytes.

After the reception of the authorization response message, the terminal processes each issuer script template in the sequence it appears in field 55 of the authorization response message. For each template the terminal performs the following processing:

Create a new data structure issuer script results of 5 bytes (see Appendix A5 in Book 4 [3]), which will store the results concerning the processing of the commands contained in the current issuer script template. Add this data structure at the end of a byte string containing the data structures corresponding to other templates that were already processed .
Reset the command counter that keeps the number of Issuer Script Command APDU(s) identified in the current issuer script template.
Parse the value field of the current template.
- Check whether the Issuer Script Identifier (tag 9F18) is present. In the affirmative case, copy the value field of this data object into bytes 2 to 5 in the issuer script results. The Issuer Script Identifier is meaningful to the issuer when interpreting the issuer script results reported by the terminal after sending of the post-issuance commands to the ICC.
- Create a first-in-first-out stack (FIFO), where each element contains the value field of one Issuer Script Command APDU data object (tag 86) separated from the value field of the template. Each new element added in the stack increments the command counter.
The processing sequence described below is performed before the second GENERATE AC , if the current template was identified with tag 71, or after the second GENERATE AC , in case the current template was identified with tag 72. Repeat the following steps a number of times equal to the command counter:
- Pop the C-APDU kept in the current element of the FIFO stack indicated by the stack pointer.
- Deliver this C-APDU to the ICC.
- Examine only the status word SW1 in the R-APDU delivered by the ICC.
- If SW1 indicates normal processing (SW1 = 90) or warning (SW1 = 62 or 63), the processing continues with the next Issuer Script Command APDU stored in the stack. If the command counter indicates that this is the first C-APDU that is processed, set to 1 bit 3, "Script processing was performed", in byte 1 of the TSI.
- If SW1 indicates an error condition, the processing does not continue with other C-APDU(s) in the stack. The terminal shall set the first nibble of the first byte in the issuer script results to 1, "Script processing failed". The terminal shall write the sequence number of the Issuer Script Command APDU that reported the error in the second nibble of the first byte in the issuer script results. This sequence number equals the value of the command counter, when less than E, or otherwise the sequence number is set to F. The terminal sets to 1 bit 6, "Script processing failed before final GENERATE AC ", in the byte 5 of the TVR, if the current template is encoded with tag 71. The terminal sets to 1 bit 5, "Script processing failed after final GENERATE AC", in byte 5 of the TVR, if the current template is encoded with tag 72.
When the processing of the entire sequence of Issuer Script Command APDU(s) is successfully performed, the terminal sets up the first nibble of the first byte in the issuer script results to 2, "Script processing successful". The terminal shall write the value 0 in the second nibble of the first byte in the issuer script results.

6.10.2 Post-Issuance Commands

The post-issuance commands can be divided into two groups:

Commands that change the status of an application or of the entire card, including APPLICATION BLOCK , APPLICATION UNBLOCK , and CARD BLOCK (see Sections 2.5.1, 2.5.2, and 2.5.3 in Book 3 [1]);
Commands that change the values of some internal parameters, like the status of a PIN, of some cryptographic keys, or a PIN value, or the values of the data elements associated with the EMV ¢ application that participates in the card risk management processing. This category includes the EMV ¢ post-issuance command PIN CHANGE/UNBLOCK (see Section 2.5.10 in Book 3 [1]). Payment systems and issuers may define supplementary commands tailored to their specific needs.

The post-issuance commands use secure messaging:

The integrity and authenticity of the issuer is achieved using a MAC.
The confidentiality of cryptographic keys or of a PIN value to be updated in the EMV ¢ application is achieved through symmetric key encryption.