6.3 Read application data

During the read application data stage, which immediately follows the initiate application processing, the terminal proceeds to the reading according to the AFL of the publicly available information from the card. While obtaining the data objects available in the card, the terminal checks whether all the mandatory data objects are present. The processing performed by both the card and the terminal during the read application data stage is schematized in Figure 6.4.

Figure 6.4: Read application data.

6.3.1 AFL processing

First, the terminal processes sequentially the entries of the AFL = F1 F2 Fn , according to the algorithm listed below.

Step 1: For each 4-byte entry Fi in the AFL, i = 1, , n , repeat the sequence of steps described below.
Step 2: Set up the parameter P2, reference control parameter, of the READ RECORD (Section 4.3.2.1) command with the SFI value read from the first byte of Fi , representing the reference of the current AEF.
Step 3: Check whether the Fi is correctly formatted according to the principles explained in Section 5.8.1. If there is an inconsistency, abort the processing of the current transaction.

Set up the RecordCounter counter to the value of the first record number of the AEF, read in the second byte of the Fi . Set up LastRecord-Number to the value of the last record number of the AEF, obtained from the third byte of Fi .
Step 4: Set up the parameter P1, record number, of the READ RECORD command to the value of the RecordCounter counter. Issue the command READ RECORD to the card.
Step 5: If the R-APDU received from the card reports SW1SW2 = 9000, parse the AEF Data Template with tag 70 received in the R-APDU. Store all the data objects obtained from the card and check their consistency according to the rules explained in Section 6.3.2.

If the consistency rules regarding the data obtained from the card are not observed , the terminal will abort the processing.
Step 6: If LastRecordNumber is greater than the RecordCounter, increment this counter and go back to step 4. Otherwise, continue with Step 7.
Step 7: If the current AEF file entry Fi is not the last one, consider the following AEF entry with index i + 1, and go back to step 2. Otherwise, the processing of the read application data is finished.

6.3.2 Consistency rules for the data objects

While dispatching each AEF Data Template received from the card, the terminal creates two data structures: the EMV ¢ data objects heap and the static data to be authenticated (see Section 5.8.1).

The EMV ¢ data objects heap is a data structure that stores all the primitive data objects dispatched from the AEF Data Templates. Every time a new primitive data object is added to the heap, the terminal observes the following rules:

A data object with an unknown tag is not included in the heap.
All known data objects, regardless of whether their presence in the card is mandatory or optional, are included in the heap.
The presence of redundant data objects is not allowed in the heap. The terminal will abort the processing of the current transaction immediately if a collision of two data objects with the same tag is detected .

When the read application data processing ends, the terminal verifies the presence of the mandatory data objects in the EMV ¢ data objects heap. The presence of the following data objects is mandatory (according to Table II-2 in Book 3 [1]):

Application Expiration Date (tag 5F24);
Application Primary Account Number (PAN, tag 5A);
Card risk management data object list 1 (CDOL1, tag 8C);
Card risk management data object list 2 (CDOL2, tag 8D).

The terminal also verifies whether other data objects that are mandatory only in the context of a certain AIP are present in the card or not. These data objects are those needed for:

Supporting cardholder verification (bit 5 = 1 in the first byte of AIP) ” the terminal must verify the presence in the card of the Cardholder Verification Method (CVM) List (tag 8E).
Supporting off-line SDA (bit 7 = 1 in the first byte of AIP) ”Section 6.4.2 gives the list of the data objects required by the terminal along with specific verification details. This checking is performed only after the terminal decides upon the execution of the SDA, as explained in Section 6.4.1.
Supporting off-line DDA (bit 6 = 1 in the first byte of AIP) ” Section 6.4.3 introduces the list of the data objects required by the terminal along with specific verification details. This checking is performed only after the terminal decides upon the execution of the DDA, as explained in Section 6.4.1.

Note that if the card supports off-line data authentication (either SDA or DDA), the data objects CA public key index (tag 8F) and Issuer Public Key Certificate (tag 90) should be located in the first record referred by the AFL. This recommendation is only ruled out by a payment product restriction. It is also a good practice for all the other data involved in the off-line data authentication stage to be returned by the card as soon as possible. This allows a multithread terminal to start the verification of the EMV ¢ public key certificates (Section 5.7) and of the Signed Static Application Data (tag 93) certificate (Section 5.9) in parallel with other processing. The static data to be authenticated (as denoted in the last row of Table 2 in Book 2 [2]) is a byte string that gathers the following data items:

All the records of the AEF(s) that are referred to in the AFL, and which are involved in the process of off-line data authentication;
Other data objects whose authenticity is required by the issuer but which are not stored in any of the records mentioned in the AFL. These data objects, if they exist, are listed in the Static Data Authentication Tag List (tag 90), which is an optional data object in the card.

Note that the Static Data to Be Authenticated byte string is formed by all the EMV ¢ terminals that are not "on-line only" (see Section 6.4.1), according to the rules indicated in Section 5.8.2. This byte string is considered both in the off-line SDA as well as in the off-line DDA. The static data to be authenticated is computed while the concerned records are read from the card, in order to allow multithread terminals to perform off-line data authentication in parallel with other processing.