SB n° SB-88 : Application Selection Updates (Spec Change)

Specification Bulletin No. 88 First Edition August 2011 Application Selection Updates This Specification Bulletin summarises various changes related to the Application Selection sections in EMV Books 1 & 4. This Specification Bulletin consolidates changes to the application selection-related sections of Book 1 Version 4.2 of the EMV Integrated Circuit Card Specifications for Payment Systems which were previously published in several Specification Updates and Specification Bulletins. It also describes some editorial changes made in order to improve readability and provide consistent terminology, and merges a related section of Book 4 into Book 1 to avoid unnecessary cross-referencing. Effective Dates The specification changes incorporated in this bulletin from previously published Specification Updates and Specification Bulletins and any associated testing changes are effective from the dates published in the source bulletins. Editorial changes are effective immediately.

Applicability

This Draft Specification Bulletin applies to:  EMV Integrated Circuit Card Specifications for Payment Systems Version 4.2 Book 1 Application Independent ICC to Terminal Interface Requirements  EMV Integrated Circuit Card Specifications for Payment Systems Version 4.2 Book 2 Security and Key Management  EMV Integrated Circuit Card Specifications for Payment Systems Version 4.2 Book 3 Application Specification  EMV Integrated Circuit Card Specifications for Payment Systems Version 4.2 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Related Documents  SU 69: Padding of BER-TLV Encoded Constructed Data Objects  SU 71: Change the status of the ‘Presence’ of the Application Label data element in the FCI of an ADF to mandatory  SB 75: Terminal AID  SB 78: Removal of DDF Entries from PSE Records

Description

Since the publication of EMV V4.2, several Specification Updates and Specification Bulletins have been released related to the Application Selection sections in Book 1:  SU 69: clarifies the rules for padding of EMV-defined BER-TLV encoded constructed data objects  SU 71: makes the Application Label a mandatory data element in the FCI of an ADF  SB 75: clarifies how the ‘Application Identifier (AID) – terminal’ data element should be populated.  SB 78: removes support for DDF entries within PSE records and describes the changes for removal of this support from Book 1. Since these bulletins have overlapping changes, this bulletin incorporates them into the existing EMV 4.2 application selection text to better explain the application selection process. In addition to the inclusion of the above mentioned bulletins, the following editorial updates are included:  The application selection related sections of Book 1 have been editorially improved to clarify and bring consistency to the terminology used in those sections, especially as related to the terms AID, ADF Name, and DF Name.  Section 12.3.1 was poorly structured and confusing so an editorial rewrite of that section has been done for clarification.  Book 4 section 11.3 had a large overlap with Book 1, section 12.4. Both sections have been merged into the updated Book 1 section 12.4.  After merging the relevant requirements from Book 4 section 11.3 into Book 1 section 12.4, the remaining requirements in the original Book 4 section 11.3 were all related to receipts. These requirements have been moved into (what was) Book 4 section 11.4, leaving nothing in the original Book 4 section 11.3, and thus what was Book 4 section 11.4 has now become Book 4 section 11.3. Proposed Specification Changes Please make the following changes: Books 1, 2, 3 & 4 In section 3 Definitions, replace the definition of Payment System Environment with: ‘A logical construct within the ICC, the entry point to which is a Directory Definition File (DDF) named 1PAY.SYS.DDF01. This DDF contains a Payment System Directory which in turn contains entries for one or more Application Definition Files (ADFs) which are formatted according to this specification.’ Book 1 Replace the existing sections  Part III - Files, Commands, and Application Selection,

 Part IV Annexes B & C and  Part V Common Core Definitions with those in the Addendum below. Book 3 In section 7.5 Erroneous or Missing Data in the ICC, add the following words to the end of the first sentence of the second paragraph: ‘unless otherwise specified in these specifications’. Book 4 Delete the existing section 11.3 Application Selection. Replace the text in existing section 11.4 Receipt with the text below, and renumber it to 11.3. ‘Whenever a receipt is provided, it shall contain:  the partial Application PAN of the application used for the transaction  the DF Name (tag '84') returned in the FCI of the final SELECT command, printed as hexadecimal characters  any additional data required by payment system rules.’

ADDENDUM

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Part III Files, Commands, and Application Selection August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 10 Files An application in the ICC includes a set of items of information, often contained within files. These items of information may be accessible to the terminal after a successful application selection. An item of information is called a data element. A data element is the smallest piece of information that may be identified by a name, a description of logical content, a format, and a coding. It is up to the issuer to ensure that data in the card is of the correct format. The data element directory defined in Annex B includes those data elements that may be used for application selection. Data elements used during application selection that are not specified in Annex B are outside the scope of these specifications.

10.1 File Structure The file organisation applying to this specification is deduced from and complies with the basic organisations as defined in ISO/IEC 7816-4. This section describes the file structure of applications conforming to this specification. The files within the ICC are seen from the terminal as a tree structure. Every branch of the tree is an Application Definition File (ADF) or a Directory Definition File (DDF). An ADF is the entry point to one or more Application Elementary Files (AEFs). An ADF and its related data files are seen as being on the same branch of the tree. A DDF is an entry point to AEFs, ADFs or other DDFs.

10.1.1 Application Definition Files The tree structure of ADFs:  Enables the attachment of data files to an application.  Ensures the separation between applications.  Allows access to the logical structure of an application by its selection. An ADF is seen from the terminal as a file containing only data objects encapsulated in its file control information (FCI) as shown in Table 45. August 2011

10 Files 10.1 File Structure EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 10.1.2 Application Elementary Files The structure and use of AEFs is application dependent. For the EMV Debit/Credit application, the files are described in Book 3.

10.1.3 Mapping of Files onto ISO/IEC 7816-4 File Structure The following mapping onto ISO/IEC 7816-4 applies:  A dedicated file (DF) as defined in ISO/IEC 7816-4 and containing a FCI is mapped onto an ADF or a DDF. It may give access to elementary files and DFs. The DF at the highest level of the card is the master file (MF).  An elementary file (EF) as defined in ISO/IEC 7816-4 is mapped onto the AEF. An EF is never used as an entry point to another file. If DFs are embedded, retrieval of the attached EF is transparent to this specification.

10.1.4 Directory Structure When the Payment System Environment (PSE) as described in section 12.2.2 is present, the ICC shall maintain a directory structure for the list of applications within the PSE that the issuer wants to be selected by a directory. In that case, the applications are listed in a Payment System Directory file (DIR file), the location of which is indicated in the FCI of the PSE DDF. The directory structure allows for the retrieval of an application using its ADF Name. The location of the DIR file shall be coded in the response message to the selection of the PSE (see the SELECT command). The DIR file is an AEF (in other words, an EF) with a record structure according to this specification including the following data objects according to ISO/IEC 7816-4:  One or more records that each contains one or more Application Templates (tag '61') containing an ADF directory entry, that is, DF Name (see Table 46).  Optionally, other data objects present within a Directory Discretionary Template (tag '73'). The data objects contained in this template are outside the scope of this specification. Directories are optional within an ICC, and when present there is no defined limit to the number of such directories that may exist. Each such directory is located by a directory SFI data object contained in the FCI of each DDF.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 10 Files 10.2 File Referencing 10.2 File Referencing A file may be referred to by a name or a SFI depending on its type.

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

10.2.2 Referencing by SFI SFIs are used for the selection of AEFs

Any AEF within a given application is referenced by a SFI coded on 5 bits in the range 1 to 30. The coding of the SFI is described in every command that uses it. A SFI shall be unique within an application. August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 11 Commands 11.1 Message Structure Messages are transported between the terminal and the card according to the transmission protocol selected at the ATR (see Part II). The terminal and the card shall also implement the physical, data link, and transport layers as defined in Part II. To run an application, an additional layer called application protocol is implemented in the terminal. It includes steps consisting of sending a command to the card, processing it in the card, and sending back the response to the terminal. All commands and responses referred to in the remainder of this Book are defined at the application layer. The command message sent from the application layer and the response message returned by the card to the application layer are called Application Protocol Data Units (APDU). A specific response corresponds to a specific command. These are referred to as APDU command-response pairs. In an APDU command-response pair, the command message and the response message may contain data. This section describes the structure of the APDU command-response pairs necessary to the application protocols defined in this specification. This Book describes only those commands necessary to the functioning of application selection. All other commands shall be implemented as required by specific applications, but shall conform to the APDU structures (formats) defined in Book 3, Part II. August 2011

11 Commands 11.1 Message Structure EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 11.1.1 Command APDU Format The command APDU consists of a mandatory header of four bytes followed by a conditional body of variable length, as shown in Figure 15: CLA INS P1 P2 Lc Data Le  Mandatory Header   Conditional Body  Figure 15: Command APDU Structure The number of data bytes sent in the command APDU is denoted by Lc (length of command data field). The maximum number of data bytes expected in the response APDU is denoted by Le (length of expected data). When Le is present and contains the value zero, the maximum number of data bytes available ( 256) is requested. READ RECORD and SELECT commands issued during application selection and all case 2 and case 4 commands issued according to Book 3 shall have Le = '00'. The content of a command APDU message is as shown in Table 36: Code CLA INS P1 P2 Lc Data Le Description Class of instruction Instruction code Instruction parameter 1 Instruction parameter 2 Number of bytes present in command data field String of data bytes sent in command (= Lc) Maximum number of data bytes expected in data field of response Length 1 1 1 1 0 or 1 var. 0 or 1 Table 36: Command APDU Content The different cases of command APDU structure are described in Table 35.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 11 Commands 11.2 READ RECORD Command-Response APDUs 11.1.2 Response APDU Format The response APDU format consists of a conditional body of variable length followed by a mandatory trailer of two bytes, as shown in Figure 16: Data SW1 SW2  Body   Trailer  Figure 16: Response APDU Structure The number of data bytes received in the response APDU is denoted by Lr (length of response data field). Lr is not returned by the transport layer. The application layer may rely on the object oriented structure of the response message data field to calculate Lr if needed. The trailer indicates in two bytes the processing state of the command as returned by the transport layer. The content of a response APDU message is as shown in Table 37: Code Data SW1 SW2 Description String of data bytes received in response Command processing status Command processing qualifier Table 37: Response APDU Content Length var(= Lr) 1 1 11.2 READ RECORD Command-Response APDUs 11.2.1 Definition and Scope The READ RECORD command reads a file record in a linear file. The response from the ICC consists of returning the record. August 2011

11 Commands 11.2 READ RECORD Command-Response APDUs EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 11.2.2 Command Message The READ RECORD command message is coded according to Table 38: Code CLA INS P1 P2 Lc Data Le Value '00' 'B2' Record number Reference control parameter (see Table 39) Not present Not present '00' Table 38: READ RECORD Command Message Table 39 defines the reference control parameter of the command message: b8 b7 b6 b5 b4 b3 b2 b1 Meaning xxx x x SFI 1 0 0 P1 is a record number Table 39: READ RECORD Command Reference Control Parameter 11.2.3 Data Field Sent in the Command Message The data field of the command message is not present.

11.2.4 Data Field Returned in the Response Message The data field of the response message of any successful READ RECORD command contains the record read. Records read during application selection are directory records which are formatted as in section 12.2.3. The format of records read during application processing is application dependent.

11.2.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 11 Commands 11.3 SELECT Command-Response APDUs 11.3 SELECT Command-Response APDUs 11.3.1 Definition and Scope The SELECT command is used to select the PSE, a DDF, or an ADF corresponding to the submitted file name or AID. The selection of an application is described in section 12. A successful execution of the command sets the path to the PSE, DDF, or ADF. Subsequent commands apply to AEFs associated with the selected PSE, DDF, or ADF using SFIs. The response from the ICC consists of returning the FCI. August 2011

11 Commands 11.3 SELECT Command-Response APDUs EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 11.3.2 Command Message The SELECT command message is coded according to Table 40: Code CLA INS P1 P2 Lc Data Le Value '00' 'A4' Reference control parameter (see Table 41) Selection options (see Table 42) '05'–'10' File name '00' Table 40: SELECT Command Message Table 41 defines the reference control parameter of the SELECT command message: b8 b7 b6 b5 b4 b3 b2 b1 Meaning 000 0 0 1 Select by name 0 0 Table 41: SELECT Command Reference Control Parameter Table 42 defines the selection options P2 of the SELECT command message: b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 First or only occurrence 1 0 Next occurrence Table 42: SELECT Command Options Parameter

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 11 Commands 11.3 SELECT Command-Response APDUs 11.3.3 Data Field Sent in the Command Message The data field of the command message contains the PSE name or the AID to be selected. During final selection of the application to be used, the data field shall be the DF Name if List of AIDs selection has been used, or ADF Name if PSE selection has been used.

11.3.4 Data Field Returned in the Response Message The data field of the response message contains the FCI specific to the selected PSE, DDF, or ADF. The tags defined in Table 43, Table 44, and Table 45 apply to this specification. No additional data elements shall be present in the FCI template (tag '6F') returned in the response to the SELECT command other than those contained in template 'BF0C'. Padding is not allowed within the FCI returned by the card. Terminals shall accept and correctly parse an FCI containing padding unless the FCI would be rejected due to other errors. Data elements present in templates '6F' and/or 'BF0C' that are not expected or understood by the terminal because the terminal does not support any issuer-specific processing shall be ignored. Table 43 defines the FCI returned by a successful selection of the PSE: Tag Value '6F' FCI Template '84' DF Name 'A5' FCI Proprietary Template '88' SFI of the Directory Elementary File '5F2D' Language Preference '9F11' Issuer Code Table Index 'BF0C' FCI Issuer Discretionary Data 'XXXX' (Tag constructed according to Book 3, Annex B) 1 or more additional proprietary data elements from an application provider, issuer, or IC card supplier, or EMV-defined tags that are specifically allocated to 'BF0C' Presence M M M M O O O O Table 43: SELECT Response Message Data Field (FCI) of the PSE August 2011

11 Commands 11.3 SELECT Command-Response APDUs EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Table 44 defines the FCI returned by a successful selection of a DDF: Tag Value '6F' FCI Template '84' DF Name 'A5' FCI Proprietary Template '88' SFI of the Directory Elementary File 'BF0C' FCI Issuer Discretionary Data 'XXXX' (Tag constructed according to Book 3, Annex B) 1 or more additional proprietary data elements from an application provider, issuer, or IC card supplier, or EMV-defined tags that are specifically allocated to 'BF0C' Presence M M M M O O Table 44: SELECT Response Message Data Field (FCI) of a DDF

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 11 Commands 11.3 SELECT Command-Response APDUs Table 45 defines the FCI returned by a successful selection of an ADF: Tag Value '6F' FCI Template '84' DF Name 'A5' FCI Proprietary Template '50' Application Label '87' Application Priority Indicator '9F38' PDOL '5F2D' Language Preference '9F11' Issuer Code Table Index '9F12' Application Preferred Name 'BF0C' FCI Issuer Discretionary Data '9F4D' Log Entry 'XXXX' (Tag constructed according to Book 3, Annex B) 1 or more additional proprietary data elements from an application provider, issuer, or IC card supplier, or EMV-defined tags that are specifically allocated to 'BF0C' Presence M M M M O O O O O O O O Table 45: SELECT Response Message Data Field (FCI) of an ADF 11.3.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command. ICC support for the selection of a DF using only a partial DF Name is not mandatory. However, if the ICC does support partial name selection, it shall comply with the following:  If, after a DF has been successfully selected, the terminal repeats the SELECT command having P2 set to the Next Occurrence option (see Table 42) and with the same partial DF Name, the card shall select a different DF matching the partial name, if another such DF exists.  Repeated issuing of the same command with no intervening application level commands shall retrieve all such files, but shall retrieve no file twice. August 2011

11 Commands 11.3 SELECT Command-Response APDUs EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements  After all matching DFs have been selected, repeating the same command again shall result in no file being selected, and the card shall respond with SW1 SW2 = '6A82' (file not found).

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12.1 Overview of Application Selection During an EMV card session as defined in section 6.1.1, application selection using the commands and techniques described in sections 11 and 12 shall be the first process performed immediately after contact activation/reset of the card and prior to the first application function. If a proprietary processing session (including any proprietary application selection method) is performed immediately before or after an EMV card session, there is no requirement to remove/reinsert the card between the sessions. However, if proprietary processing occurs before the EMV card session, the card contacts shall be deactivated before starting the EMV card session. This section describes the application selection process from the standpoint of both the card and the terminal. It specifies the logical structure of data and files within the card that are required for the process, and then describes the terminal logic using the card structure. It is not recommended that the ICC and the terminal use implicit selection as defined in ISO 7816, as it is not useful in an interchange environment. If used, it shall be performed outside the EMV card session as defined in section 6.1.1. The application selection process described in this section is the process by which the terminal uses data in the ICC according to protocols defined herein to determine the terminal program and the ICC application to be used in processing a transaction. The process is described in two steps: 1. Create a list of ICC applications that are supported by the terminal. (This list is referred to below using the name ‘candidate list.’) This process is described in section 12.3. 2. Select the application to be run from the list generated above. This process is described in section 12.4. This section of the specification describes the necessary information in the card and two terminal selection algorithms that yield the correct results. Other terminal selection algorithms that yield the same results are permitted in place of the selection algorithms described here. August 2011

12 Application Selection 12.1 Overview of Application Selection EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements A payment system application is comprised of the following:  A set of files in the ICC providing data customised by the issuer  Data in the terminal provided by the acquirer or the merchant  An application protocol agreed upon by both the ICC and the terminal Applications supported by the terminal are identified by AIDs conforming to ISO/IEC 7816-4. Applications supported by the ICC are identified by DF Names conforming to ISO/IEC 7816-4. See section 12.2.1 below. The techniques chosen by the payment systems and described herein are designed to meet the following key objectives:  Ability to work with ICCs with a wide range of capabilities.  Ability for terminals with a wide range of capabilities to work with all ICCs supporting payment system applications according to this specification.  Conformance with ISO standards.  Ability of ICCs to support multiple applications, not all of which need to be payment system applications.  Ability for ICCs to provide multiple sets of applications to be supported by a single terminal program. (For example, a card may contain multiple credit/debit applications, each representing a different type or level of service or a different account).  As far as possible, provide the capability for applications conforming with this specification to co-reside on cards with presently existing applications.  Minimum overhead in storage and processing.  Ability for the issuer to optimise the selection process. The set of data that the ICC contains in support of a given application is defined by an ADF selected by the terminal using a SELECT command and an Application File Locator (AFL) returned by the ICC in response to a GET PROCESSING OPTIONS command.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12.2 Data in the ICC Used for Application Selection 12.2 Data in the ICC Used for Application Selection 12.2.1 Coding of Payment System Application Identifier The structure of AIDs, ADF Names and DF Names is according to ISO/IEC 7816-4 and consists of two parts: 1. A Registered Application Provider Identifier (RID) of 5 bytes, unique to an application provider and assigned according to ISO/IEC 7816-4. 2. An optional field assigned by the application provider of up to 11 bytes. This field is known as a Proprietary Application Identifier Extension (PIX) and may contain any 0–11 byte value specified by the provider. The meaning of this field is defined only for the specific RID and need not be unique across different RIDs. Additional ADFs defined under the control of other application providers may be present in the ICC but shall avoid duplicating the range of RIDs assigned to payment systems. Compliance with ISO/IEC 7816-4 will assure this avoidance. August 2011

12 Application Selection 12.2 Data in the ICC Used for Application Selection EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12.2.2 Structure of the PSE The PSE is accessed via a DDF with the name ‘1PAY.SYS.DDF01’. The presence of this DDF in the ICC is optional but, if present, it shall comply with this specification. If it is present, this DDF is mapped onto a DF within the card, which may or may not be the MF, and shall contain a Payment System Directory. The FCI of this DDF shall contain at least the information defined for all DDFs in section 11 and, optionally, the Language Preference (tag '5F2D') and the Issuer Code Table Index (tag '9F11'). The Language Preference and Issuer Code Table Index are optional data objects that may occur in two places: the FCI of the PSE and the FCI of ADF files. If either of these data elements is present in one location but not the other, the terminal shall use the data element that is present. If either data element is present in both locations but has different values in the two locations, the terminal may use either value.9 The directory attached to the PSE DDF contains entries for ADFs that are formatted according to this specification, although the applications defined by those ADFs may or may not conform to this specification. The directory is not required to have entries for all ADFs in the card. However, if the PSE exists, only applications that are revealed by reading the directory can be assured of international interoperability. See Annex C for examples of the internal logic structure of an ICC containing the PSE. 9 A terminal building a candidate list using the process described in section 12.3.2 will encounter the values specified in the FCI of the PSE and will not see the values specified in the FCI of the ADF until the application to be run has been chosen. A terminal building the candidate list using the process described in section 12.3.3 will encounter the values specified in the FCI of the ADFs. To ensure consistent interface to the cardholder, the values must be the same.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12.2 Data in the ICC Used for Application Selection 12.2.3 Coding of a Payment System Directory A Payment System Directory is a linear EF file identified by a SFI in the range 1 to 10. The SFI for the Payment System Directory AEF is contained in the FCI of the DDF to which the directory is attached. The Payment System Directory is read using the READ RECORD command as defined in section 11. A record may have several directory entries, but a directory entry shall always be encapsulated in its entirety in a single record. Each record in the Payment System Directory is a constructed data object, and the value field is comprised of one or more directory entries as described below in Table 46: Tag Data Tag Length Directory... Tag Length Directory '70' Length '61' of entry 1 '61' of entry n (L) directory (ADF) directory (ADF) entry 1 entry n Table 46: Payment System Directory Record Format Payment Systems Directory records shall not contain any entries for DDFs. If the terminal encounters a directory entry for a DDF in one of these records, it may ignore it or may optionally process the DDF, but any such processing is outside the scope of EMV. Each entry in a Payment System Directory is the value field of an Application Template (tag '61') and contains the information according to Table 47. No additional data elements shall be present in the Payment System Directory Record (tag ‘70’) other than those contained in template ‘73’. Data elements present in the Payment System Directory Record, template '61', or template '73' that are not expected or understood by the terminal because the terminal does not support any issuer-specific processing, shall be ignored. August 2011

12 Application Selection 12.2 Data in the ICC Used for Application Selection EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Tag '4F' '50' '9F12' '87' '73' Length 5–16 1–16 1–16 1 var. 'XXXX' (Tag construct- ed according to Book 3, Annex B) Value ADF Name Application Label Application Preferred Name Application Priority Indicator (see Table 48) Directory Discretionary Template var. 1 or more additional proprietary data elements from an application provider, issuer, or IC card supplier, or EMV-defined tags that are specifically allocated to template '73' Presence M M O O O 11 O Table 47: ADF Directory Entry Format b8 b7–b5 b4–b1 Definition 1 Application cannot be selected without confirmation by the cardholder 0 Application may be selected without confirmation by the cardholder xxx RFU 0000 No priority assigned xxxx (except 0000) Order in which the application is to be listed or selected, ranging from 1–15, with 1 being highest priority Table 48: Format of Application Priority Indicator 11 Other data objects not relevant to this specification may appear in this constructed data object.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12.2 Data in the ICC Used for Application Selection 12.2.4 Error Handling for FCI Response Data The data elements Application Label, Application Preferred Name, Issuer Code Table Index, and Language Preference are present for the convenience of the cardholder and are not critical to the successful processing of application selection. If these data elements are present in the FCI, the issuer is responsible for their correct encoding. If the Application Label data element is not present in the FCI of an ADF, the terminal shall not terminate the card session but shall proceed with application selection. Terminals shall not enforce the correct formatting of these data elements. If Application Preferred Name or Application Label contains a character that is not valid for the defined format, the terminal shall display the character if it is able to, or if the terminal is unable to display the invalid character, it should omit the character or substitute a space character or any other appropriate character. Otherwise, if the terminal detects format errors in any of these data elements, the terminal shall disregard these errors and act as if the response provided by the card did not contain these data elements. More specifically, the terminal shall not terminate the card session but shall proceed with application selection. If the terminal does not understand the value in Issuer Code Table Index or Language Preference, it shall treat the data element as not present. August 2011

12 Application Selection 12.3 Building the Candidate List EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12.3 Building the Candidate List A terminal shall always support application selection using the List of AIDs method as described in section 12.3.3. A terminal may additionally support application selection using the PSE method as described in section 12.3.2. If the card contains no PSE, the procedure described in section 12.3.3 must be followed. The terminal may know other ways that are not described in this section to locate proprietary applications or to eliminate specific applications in the ICC from consideration. This is permitted as long as all interoperable applications can be located in the ICC using the techniques described here.

12.3.1 Matching Terminal Applications to ICC Applications The terminal shall maintain a list of applications supported by the terminal identified by their AIDs. The terminal determines which applications in the ICC are supported by comparing the AIDs for applications supported by the terminal with the DF Names12 of applications supported by the ICC. For each of the AIDs within the list of applications supported by the terminal, the terminal shall use the Application Selection Indicator (ASI) as an indicator of the matching criterion to use.  If the ASI indicates that the terminal supports the ICC application only when the AID in the terminal has the same length and value as the DF Name then this limits the ICC to at most one matching ADF.  If the ASI indicates that the terminal supports the ICC application when the DF Name begins with the entire AID kept within the terminal then this allows the ICC to have multiple ADFs matching the terminal AID by adding unique information to the DF Name used by each of the ADFs. 12 Depending upon the method used to build the candidate list, the names in the list will be ADF Names found in directory entries if the PSE selection method is used or DF Names found in the FCIs returned to SELECT commands if the List of AIDs method is used. For readability in this section, the term DF Name is used in place of either.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12.3 Building the Candidate List If the ICC does not support partial name selection as described in section 11.3.5, the DF Name of the ADF must be an exact match with the terminal AID. If the ICC supports partial name selection as described in section 11.3.5 and has multiple ADFs supported by a single terminal AID, all of the matching DF Names must be distinguished by adding unique data to the PIX. All of the matching DF Names shall be longer than the corresponding terminal AID.

12.3.2 Using the PSE If a terminal chooses to support application selection using the PSE method, it shall follow the procedure described in this section to determine the applications supported by the card. Figure 17 is a flow diagram of the logic described here. The terminal performs the following steps: 1. The terminal begins by selecting the PSE using a SELECT command as described in section 11 using a file name of ‘1PAY.SYS.DDF01’. This establishes the PSE and makes the Payment System Directory accessible. If the card is blocked or the SELECT command is not supported (both conditions represented by SW1 SW2 = '6A81'), the terminal terminates the session. If there is no PSE in the ICC, the ICC shall return '6A82' (‘File not found’) in response to the SELECT command for the PSE. In this case, the terminal shall use the List of AIDs method described in section 12.3.3. If the PSE is blocked, the ICC shall return '6283'. In this case, the terminal shall use the List of AIDs method described in section 12.3.3. If the ICC returns SW1 SW2 = '9000', the terminal proceeds to step 2. If the card returns any other value in SW1 SW2, the terminal shall use the List of AIDs method described in section 12.3.3. If any error, including a SW1 SW2 different from '90 00' or '6A 83', occurs in steps 2 through 4, the terminal shall clear the candidate list and restart the application selection process using the List of AIDs method described in section 12.3.3 to find the matching applications. August 2011

12 Application Selection 12.3 Building the Candidate List EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 2. The terminal uses the Directory SFI from the FCI returned and reads all the records in the Payment System Directory beginning with record number 1 and continuing with successive records until the card returns SW1 SW2 = '6A83', which indicates that the record number requested does not exist. (The card shall return '6A83' if the record number in the READ RECORD command is greater than the number of the last record in the file). If the card returns SW1 SW2 = '6A83' in response to a READ RECORD for record number 1 for the Payment System Directory, no directory entries exist, and step 5 (below) applies. For each record in the Payment System Directory, the terminal begins with the first directory entry and processes each directory entry in turn as described in steps 3 and 4. If there are no directory entries in the record, the terminal proceeds to the next directory record. 3. If the ADF Name in the directory entry matches one of the applications supported by the terminal as defined in section 12.3.1, the application joins the candidate list for final application selection under control of the ASI maintained in the terminal for that AID. The ASI indicates whether the AID in the terminal shall match exactly (both in length and name) or need only partially match the associated ADF Name in the directory entry (tag '4F'). The application is added to the candidate list in either of the following cases:  the ADF Name in the directory entry retrieved is an exact match, or  the ASI for the AID in the terminal indicates that a partial match is allowed. The application is not added to the candidate list if the ADF Name in the directory entry retrieved is not an exact match and the ASI for the AID in the terminal indicates that an exact match is required. 4. When the terminal finishes processing all entries in the last record of the Payment System Directory, all ADFs that can be found by this procedure have been determined. The search and the candidate list are complete. If at least one matching ADF Name was found, the terminal continues processing as described in section 12.4. 5. If steps 1 through 4 yield no directory entries that match applications supported by the terminal, the terminal shall use the list of AIDs method described in section 12.3.3 to find a match.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12.3 Building the Candidate List Begin Application Selection If the terminal and card support implicit selection as defined by ISO 7816-4, it is performed prior to this step. Terminate Session Terminal Supports PSE? Yes Select DFNAME = No '1PAY.SYS.DDF01' Yes S=W'61A8S1W' ?2 No PSE No Found? Yes PSE Yes Blocked? No Empty candidate list Selection from terminal list See “Using a List of AIDs” in next section Get SFI for directory from FCI Set record number for read to 1 Read directory record Record found? Yes Get first entry from Yes record A Is there No an entry in this record? Terminal No supports application? Yes No ADF is exact match of AID? Yes Terminal Application Selection Indicator No allows partial match? Yes Add ADF to candidate list No Are there any No entries on the candidate list? Yes Candidate list is complete. Choose application from candidate list. Is there another entry in this record? Yes Get next entry Increment record No number for next read by 1 A August 2011 Figure 17: Terminal Logic Using Directories

12 Application Selection 12.3 Building the Candidate List EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12.3.3 Using a List of AIDs If either the card or the terminal does not support the PSE method or if the terminal is unable to find a matching application using the Payment System Directory selection method, the terminal shall use a list of AIDs that it supports to build the candidate list. Figure 18 is a flow diagram of the logic described here. The terminal performs the following steps: 1. The terminal issues a SELECT command using the first AID13 in the terminal list as the file name. 2. If the SELECT command fails because the card is blocked or the command is not supported by the ICC (SW1 SW2 = '6A81'), the terminal terminates the card session. 3. If the SELECT command is successful (SW1 SW2 = '9000' or '6283'), the terminal compares the AID with the DF Name field returned in the FCI. The DF Name will either be identical to the AID (including the length), or the DF Name will start with the AID but will be longer. If the names are identical, the terminal proceeds with step 4. If the DF Name is longer, the card processed the command as a partial name selection, and the terminal proceeds to step 6. If the card returns any other status or if mandatory data is missing from the SELECT response or if the FCI contains formatting errors not described in Section 12.2.4, the terminal proceeds to Step 5 without adding the DF Name to the candidate list. 4. If the SELECT command is successful (SW1 SW2 = '9000'), the terminal adds the DF Name and other information14 from the FCI to the candidate list and proceeds to step 5. If the application is blocked (SW1 SW2 = '6283'), the terminal proceeds to step 5 without adding the DF Name to the candidate list. 5. The terminal issues another SELECT command using the next AID in its list and returns to step 3. If there are no more AIDs in the list, the candidate list is complete, and the terminal proceeds as specified in section 12.4. 13 To assist in a clear understanding of the process described in this section, it is necessary to distinguish between the application identifier kept in the terminal and the application identifier kept in the ICC. As can be seen in section 12.3.1, these might not be identical even for matching applications. In this procedure, the term AID is used for the application identifier kept in the terminal, and DF Name is used for the application identifier in the card. 14 The Application Label and Application Preferred Name must also be saved if the cardholder will be provided a list during final selection. The DF Name and the Application Priority Indicator will be required in any case.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12.3 Building the Candidate List 6. Along with the AID list, the terminal keeps an Application Selection Indicator that indicates whether the card may have multiple occurrences of the application within the card. The terminal checks this indicator. If the indicator says that an exact match (in both length and name) is required, the terminal does not add the DF Name and other information from the FCI to the candidate list, but proceeds to step 5. If multiple occurrences are permitted, the partial name match is sufficient. If the application is not blocked (SW1 SW2 = '9000'), the terminal adds the DF Name and other information from the FCI to the candidate list and proceeds to step 7. If multiple occurrences are permitted but the application is blocked (SW1 SW2  '9000'), the terminal proceeds to step 7 without adding the DF Name or other information from the FCI to the candidate list. 7. The terminal repeats the SELECT command using the same command data as before, but changes P2 in the command to '02' (Select Next). If the ICC returns SW1 SW2 = '9000', '62xx', or '63xx', the terminal returns to step 3. If it returns a different SW1 SW2, the terminal goes to step 5. August 2011

12 Application Selection 12.3 Building the Candidate List EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Must be identical, including length Begin Application Selection Empty candidate list Get first AID from terminal list SELECT File using DF name = AID SW1 SW2 Ye = '6A81' ? No File found including all mandatory data? Ye DFname in FCI = AID? No Ye Application blocked? No Check Application Selection Indicator in terminal No Add FCI information to candidate list Partial name No match allowed? Terminate Session Yes Is there Ye another AID in list? No Get next AID from list Finished. Go to final selection SELECT File using DF name = AID Ye SELECT NEXT with DF name = terminal AID Application blocked? Ye No Add FCI information to candidate list Ye SW1 SW2 = No 9000, 62xx, or 63x Figure 18: Using the List of AIDs in the Terminal

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements 12 Application Selection 12.4 Final Selection 12.4 Final Selection The terminal should support the ability to allow the cardholder to select an application or to confirm the application proposed by the terminal. When the terminal displays an application to the cardholder, it shall display:  the Application Preferred Name, if present and if the Issuer Code Table Index indicating the part of ISO/IEC 8859 to use is present and supported by the terminal (as indicated in Additional Terminal Capabilities)  otherwise the Application Label, if present, by using the common character set of ISO/IEC 8859 (see Book 4 Annex B) Once the terminal determines the list of mutually supported applications, it proceeds as follows: 1. If there are no mutually supported applications, the transaction is terminated. 2. If there is only one mutually supported application, the terminal checks b8 of the card’s Application Priority Indicator for that application if present.  If b8 = '0', the terminal selects the application.  If b8 = '1' and the terminal provides for confirmation by the cardholder, the terminal requests confirmation and selects the application if the cardholder approves. If the terminal does not provide for confirmation by the cardholder, or if the terminal requests confirmation and the cardholder does not approve, the terminal terminates the session. 3. If there is more than one mutually supported application, then:  if the terminal supports the ability to allow the cardholder to select an application the terminal shall offer a selection to the cardholder as described in step 4  if the terminal does not support the ability to allow the cardholder to select an application, the terminal makes the selection itself as described in step 5. Step 4 is the preferred method. 4. When the terminal offers a selection to the cardholder, then:  Applications where the card’s Application Priority Indicator is present shall be presented in priority sequence as indicated by the Application Priority Indicator with the highest priority application offered first. Where the same priority is assigned to multiple applications, the terminal may present these applications in its own preferred order or in the order encountered in the card. August 2011

12 Application Selection 12.4 Final Selection EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements  For applications where the card’s Application Priority Indicator is not present, the terminal may present these applications in its own preferred order or in the order encountered in the card. 5. When the terminal does not offer a selection to the cardholder, then the terminal shall select the highest priority application that does not require cardholder confirmation (that is, the card’s Application Priority Indicator b8 = '0') from the list of mutually supported applications. The application’s priority is determined using the same rules as described in step 4. Once the application to be run is determined by the terminal or by the cardholder, the application shall be selected. A SELECT command coded according to section 11 shall be issued by the terminal for the application using the ADF Name field (if a directory was read) or the DF Name field from the FCI (if the List of AIDs method was used) found during the building of the candidate list. On successful selection of the application to be used (SW1 SW2 = '9000' returned in response to the final SELECT command, the response contains no format errors other than those described in section 12.2.4, and the AID used in the final SELECT command exactly matches the DF Name (tag '84') returned by the ICC in the FCI), the terminal shall set the value of the terminal data element Application Identifier (AID) – terminal (tag '9F06') to the same value as the DF Name (tag '84') returned in the FCI. If transaction processing is to be continued according to Book 3, this shall be done prior to issuance of the GET PROCESSING OPTIONS command. If the command returns other than '9000' in SW1 SW2 or the SELECT response contains format errors other than those described in section 12.2.4, the application shall be removed from the candidate list, and processing shall resume at step 1. If the cardholder selects or confirms the selection of an application that is subsequently removed from the candidate list due to its being blocked or for any other reason, no application is to be selected without cardholder confirmation. If no application can be selected, the terminal shall terminate the transaction. In any case, the terminal shall inform the cardholder of the action taken (that is, by using the messages defined in Book 4 section 11.2), if appropriate.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Part IV Annexes August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table Table 49 defines those data elements that may be used for application selection and their mapping onto data objects and files.16 Table 50 lists the data elements in tag sequence. The characters used in the “Format” column are described in section 4.3, Data Element Format Convention. B1 Data Elements by Name Name Application Dedicated File (ADF) Name Application Identifier (AID) terminal Description Identifies the application as described in ISO/IEC 7816-4 Identifies the application as described in ISO/IEC 7816-4 Source ICC Terminal Format b b Table 49: Data Elements Table Template Tag Length '61' '4F' 5–16 — '9F06' 5–16 16 Annex A of Book 3 provides a complete data elements table, defining all data elements that may be used for financial transaction interchange and their mapping onto data objects and files. August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B1 Data Elements by Name Name Application Label Application Preferred Name Application Priority Indicator Application Selection Indicator Application Template Description Mnemonic associated with the AID according to ISO/IEC 7816-4 Preferred mnemonic associated with the AID Indicates the priority of a given application or group of applications in a directory For an application in the ICC to be supported by an application in the terminal, the Application Selection Indicator indicates whether the associated AID in the terminal must match the AID in the card exactly, including the length of the AID, or only up to the length of the AID in the terminal There is only one Application Selection Indicator per AID supported by the terminal Contains one or more data objects relevant to an application directory entry according to ISO/IEC 7816-4 Source ICC ICC ICC Terminal ICC Format ans with the special character limited to space ans (see section 4.3) b At the discretion of the terminal. The data is not sent across the interface b Template '61' or 'A5' '61' or 'A5' '61' or 'A5' — '70' Table 49: Data Elements Table, continued Tag '50' '9F12' '87' — '61' Length 1–16 1–16 1 See Format var. up to 252 August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B1 Data Elements by Name Name Bank Identifier Code (BIC) Dedicated File (DF) Name Directory Definition File (DDF) Name Directory Discretionary Template File Control Information (FCI) Issuer Discretionary Data File Control Information (FCI) Proprietary Template File Control Information (FCI) Template Description Uniquely identifies a bank as defined in ISO 9362. Identifies the name of the DF as described in ISO/IEC 7816-4 Identifies the name of a DF associated with a directory Source ICC ICC ICC Issuer discretionary part of the ICC directory according to ISO/IEC 7816-4 Issuer discretionary part of the FCI ICC Format var. b b var. var. Template 'BF0C' or '73' '6F' Tag '5F54' '84' Length 8 or 11 5–16 '61' '9D' 5–16 '61' '73' var. up to 252 'A5' 'BF0C' var. up to 222 Identifies the data object proprietary to ICC var. '6F' this specification in the FCI template according to ISO/IEC 7816-4 Identifies the FCI template according to ICC var. — ISO/IEC 7816-4 Table 49: Data Elements Table, continued 'A5' var. '6F' var. up to 252 August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B1 Data Elements by Name Name International Bank Account Number (IBAN) Issuer Code Table Index Issuer Country Code (alpha2 format) Issuer Country Code (alpha3 format) Industry Identification Number (IIN) Issuer URL Description Uniquely identifies the account of a customer at a financial institution as defined in ISO 13616. Indicates the code table according to ISO/IEC 8859 for displaying the Application Preferred Name Indicates the country of the issuer as defined in ISO 3166 (using a 2 character alphabetic code) Indicates the country of the issuer as defined in ISO 3166 (using a 3 character alphabetic code) The number that identifies the major industry and the card issuer and that forms the first part of the Primary Account Number (PAN) The URL provides the location of the issuer’s Library Server on the Internet Source ICC ICC ICC ICC ICC ICC Format var. n 2 a 2 a 3 n 6 ans Template 'BF0C' or '73' 'A5' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' Table 49: Data Elements Table, continued Tag '5F53' Length Var. up to 34 '9F11' 1 '5F55' 2 '5F56' 3 '42' 3 '5F50' var. August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B1 Data Elements by Name Name Language Preference Log Entry Processing Options Data Object List (PDOL) READ RECORD Response Message Template Short File Identifier (SFI) Description 1–4 languages stored in order of preference, each represented by 2 alphabetical characters according to ISO 639 Note: EMVCo strongly recommends that cards be personalised with data element '5F2D' coded in lowercase, but that terminals accept the data element whether it is coded in upper or lower case. Provides the SFI of the Transaction Log file and its number of records Contains a list of terminal resident data objects (tags and lengths) needed by the ICC in processing the GET PROCESSING OPTIONS command Contains the contents of the record read. (Mandatory for SFIs 1-10. Response messages for SFIs 11-30 are outside the scope of EMV, but may use template '70'.) Identifies the AEF referenced in commands related to a given ADF or DDF. It is a binary data object having a value in the range 1 – 30 and with the three high order bits set to zero. Source ICC ICC ICC ICC ICC Format an 2 b b var. b Template 'A5' 'BF0C' or '73' 'A5' — 'A5' Table 49: Data Elements Table, continued Tag '5F2D' '9F4D' '9F38' '70' '88' Length 2–8 2 var. var. up to 252 1 August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B1 Data Elements by Name When the length defined for the data object is greater than the length of the actual data, the following rules apply:  A data element in format n is right justified and padded with leading hexadecimal zeroes.  A data element in format a, an, or ans is left justified and padded with trailing hexadecimal zeroes. When data is moved from one entity to another (for example, card to terminal), it shall always be passed in order from high order to low order, regardless of how it is internally stored. The same rule applies when concatenating data. August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Annex B Data Elements Table B2 Data Elements by Tag B2 Data Elements by Tag Name Issuer Identification Number (IIN) Application Dedicated File (ADF) Name Application Label Language Preference Issuer URL International Bank Account Number (IBAN) Bank Identifier Code (BIC) Issuer Country Code (alpha2 format) Issuer Country Code (alpha3 format) Application Template File Control Information (FCI) Template READ RECORD Response Message Template Directory Discretionary Template Dedicated File (DF) Name Application Priority Indicator Short File Identifier (SFI) Directory Definition File (DDF) Name Application Identifier (AID) - terminal Issuer Code Table Index Application Preferred Name Processing Options Data Object List (PDOL) Log Entry File Control Information (FCI) Proprietary Template File Control Information (FCI) Issuer Discretionary Data Template 'BF0C' or '73' '61' '61' or 'A5' 'A5' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' 'BF0C' or '73' '70' — — '61' '6F' '61' or 'A5' 'A5' '61' — 'A5' '61' or 'A5' 'A5' 'BF0C' or '73' '6F' 'A5' Table 50: Data Elements Tags Tag '42' '4F' '50' '5F2D' '5F50' '5F53' '5F54' ‘5F55’ '5F56' '61' '6F' '70' '73' '84' '87' '88' '9D' '9F06' '9F11' '9F12' '9F38' '9F4D' 'A5' 'BF0C' August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Annex C Examples of Directory Structures This annex illustrates some possible logical ICC file structures. C1 Single Application Card Figure 19 illustrates a single application card with only a single level directory. In this example, the MF (with file identification of '3F00', as defined by ISO/IEC 7816-4) acts as the only DDF in the card. The MF shall be given the unique payment system’s name assigned to the first level DDF as defined in section 12.2, and the FCI of the MF shall contain the SFI data object. ‘DIR A’ in this example may or may not be the ISO DIR file, but it shall conform to this specification, including the requirement that it has a SFI in the range 1 to 10. MF DIR A ADF EF EF Figure 19: Simplest Card Structure Single Application August 2011

Annex C Examples of Directory Structures EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements C2 Single Level Directory Figure 20 gives an example of a multi-application card with a single directory. In this example, the root file (MF) does not support an application complying with this specification, and no restrictions are placed on the function of the MF. According to ISO/IEC 7816-4, a DIR file may be present but is not used by the application selection algorithm defined in section 12. Also note that the directory does not have entries for all ADFs (ADF2 to ADF5), as ADF5 is omitted. ADF5 can be selected only by a terminal that ‘knows’ ADF5 may exist in the card. The manner in which the terminal finds ADF5 is outside the scope of this specification. MF DDF1 DIR A ADF 2 EF ADF 3 EF EF ADF 4 ADF 5 EF EF EF EF Figure 20: Single Level Directory

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Annex C Examples of Directory Structures C3 Multi-Level Directory Figure 21 is an example of a multi-application card with an n level directory structure. The first level directory (‘DIR A’) has entries for 2 ADFs  ADF3 and ADF4  and a single DDF  DDF2. The directory attached to DDF2 (‘DIR B’) has entries for two ADFs  ADF21 and ADF22  and a single DDF  DDF6. DDF5 has no entry in the root directory and can be found only by a terminal that ‘knows’ of the existence of DDF5. The manner in which the terminal finds and selects DDF5 is outside the scope of this specification, but the directory attached to DF5 (‘DIR C’) may conform to this specification, and, if found by the terminal, may lead the terminal to ADFs such as DF51, DF52, and DF53. DIR D, attached to DDF6, is a third level directory and points to four files (not shown), which may be either ADFs or more DDFs. MF DDF1 DIR A DIR B DDF 2 ADF 21 ADF 22 ADF 3 ADF 4 EF EF EF DDF6 DIR D EF EF DDF 5 DIR C ADF 51 ADF 52 ADF 53 EF EF EF EF Figure 21: Third Level Directory C4 Coding of Proprietary Directories EMV does not mandate the formats for proprietary directories that may be present on the card in addition to the Payment System Directory. Directories following the structure defined in section 12.2 can be accessed using the methods described in this section. These directories can have the same format as shown in Table 46 for the Payment System Directory Record Format, and can in addition to the one or more ADF Directory Entries also contain one or more DDF Directory Entries. If present, these DDF Directory entries can have the format as shown in Table 51 below. August 2011

Annex C Examples of Directory Structures EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Tag Length Value Presence '9D' 5–16 DDF Name M '73' var. Directory Discretionary Template O17 'XXXX' var. 1 or more additional proprietary data O (Tag construct- ed according to Book 3, elements from an application provider, issuer, or IC card supplier, or EMV-defined tags that are specifically allocated to template '73' Annex B) Table 51: Example of a DDF Directory Entry Format 17 Other data objects not relevant to this specification may appear in this constructed data object.

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Part V Common Core

Definitions

August 2011

EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Common Core Definitions This Part describes an optional extension to this Book, to be used when implementing the Common Core Definitions (CCD). It is to be used in conjunction with Books 2, 3, and 4, including the Common Core Definitions part of Books 2 and 3. 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 affected Books. Changed Sections Each section heading below refers to the section in this Book 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. August 2011

Common Core Definitions EMV SB88 Book 1 Application Independent ICC to Terminal Interface Requirements Part III - Files, Commands, and Application Selection 11 Commands 11.3 SELECT Command-Response APDUs 11.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 (that is, the RID). Select Next functionality shall be supported.

August 2011