Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The organization of the file structure in the EMV standard is based on the specifications of the ISO 7816-4 standard and is described in part 2 of book 1 and part 1 of book 3 of the EMV specifications.
In the EMV file system, DF files come in two flavors: DDF (Directory Definition File) and ADF (Application Definition File).
The ADF file corresponds to a separate card application and contains (is an access point) only elementary AEF (Application Elementary File) files that store the data of this application. Internally, the ADF is selected by its SFI ID, which ranges from 1 to 30. After the ADF is selected, the SFI ID is used as an input parameter to the command that manipulates the AEF data.
Each application on the card must have its own Application ID (AID) used as the name or the beginning of the DF Name of the ADF file. Application ID can be registered (in ISO) or unregistered (private).
According to the ISO 7816-5 standard, the registered application identifier AID is encoded up to 16 bytes. The identifier consists of two parts AID = RID || PIX, where RID is a Registered Application ID of 5 bytes, PIX is a Proprietary Application Extension of up to 11 bytes.
RID is registered with ISO. For example, the corresponding RID value for all VISA AOOOOOOOOZ applications, and A000000004'h for MasterCard applications. Thus, the RID in the application identifier identifies the payment system.
The PIX values identify a specific card product for each registered RID. Listed below are examples of PIX values set by VISA and MasterCard for some of their applications.
A DDF file consists of ADF files and DDF files. Each DDF file is also selected in the card file system by its name. The criteria by which ADF files are combined (grouped) in a DDF file can vary. For example, one criterion might be the general nature of the applications that match the ADF files of the same DDF file. In particular, the DDF file that integrates payment applications is called the Payment System Environment (PSE). The name 1PAY.SYS.DDF01 is reserved for this DDF file. Chapter 7 introduces a DDF file named 2PAY.SYS.DDF01 that contains all of the card's contactless payment applications.
Another criterion for combining ADF files can be the belonging of the corresponding applications to one or another payment system operator (for example, VISA or MasterCard).
Each ADF and DDF file has an FCI Template Data Item (Tag '6F') containing those FCI header data objects that are returned to the terminal in response to a file select command. The content of the FCI Template is different for ADF and DDF files.
The FCI Template structure for the ADF file is shown in Fig. 3.3.
As seen from Fig. 3.3, the FCI Template for the ADF file consists of two required data objects:
a string (binary format of a data item) with a size of 5 to 16 bytes;
• FCI Proprietary Template (Tag'A5 '), which defines the application parameters required for the terminal to select the application, and for the card to process the transaction.
Let's dwell on the FCI Proprietary Template data object in more detail. It consists of objects presented in table. 3.7.
Tab. 3.7. FCI Proprietary Template Data Object for ADF File
The Application Label Data Object (Tag '50') is the only required element of the FCI Proprietary Template. It defines the name of the payment product corresponding to this application (for example,
MasterCard
^? 9
Maestro, Cirrus, Electron), registered by the payment system as a trademark of the card product. The Application Label Data Item is in alphanumeric format and contains one to 16 characters (format defined in ISO 7816-5). The Application Label object is designed to present the card product to the cardholder in the human-machine interface (on the terminal display) when using the card in the payment system terminal.
The Application Preferred Name data object (Tag '9F12') is optional and defines an additional name of the card product to the Application Label. The Application Preferred Name data element is represented as a string of alphanumeric characters, ranging from 1 to 16 characters, and is used as an additional identifier for the application in the HMI when the card is used in the payment system terminal. The Application Preferred Name object is introduced by the card issuer for the convenience of the cardholder. Typically, this data element is the product name, encoded only in the alphabetical encoding of the cardholder's country.
The Issuer Code Table Index data object (Tag '9F11') is optional and, according to ISO 8859, defines the alphabet encoding table used to display the Application Preferred Name string. In the case where the Application Preferred Name data object is present in the FCI Proprietary Template, the Issuer Code Table Index object is required.
The Language Preference data object (Tag '5F2D') is optional and defines from one to four languages, which, from the point of view of the issuer, are the most preferable for the dialogue between the cardholder and the terminal during the operation. Each language is encoded with two letters of the Latin alphabet in accordance with the ISO 693 standard. Two bytes are used to encode one language, so in general the length of the Language Preference data object varies from 2 to 8 bytes. The language codes in the data field of the Language Preference object are listed in descending order of priority for their respective languages.
For dialogue with the cardholder, the terminal selects the highest priority language from the list of languages of the Language Preference object supported by the terminal. If the terminal does not support any of the languages listed in the Language Preference object, the Language Preference object is ignored by the terminal.
The Application Priority Indicator data object (Tag '87') is optional and defines the order in which card applications are displayed on the POS display. The Application Priority Indicator data item is in binary format and encoded in a 1 byte string.
Bits b4, b3, b2, b of the Application Priority Indicator byte determine the value of the priority of the application. The highest priority is 1, the lowest is 15. A value of 0 means the application has no priority.
Bit b8 determines whether cardholder confirmation is required when selecting an application (b8 = 1) or not (b8 - 0). If b8 = 1, the terminal must ask the cardholder for confirmation of his consent to use this application to complete the transaction.
The PDOL data object (Processing Options Data Object List) (Tag '9F38') is optional and defines the transaction and terminal data required by the card in order to decide on the best way of processing the transaction from the point of view of the card issuer (choosing a processing "profile" transactions). The PDOL data item contains a list of tags and data object lengths required by the card (at the discretion of the issuer) to select a "profile" for processing a transaction.
Let us explain what has been said with a few examples. The PDOL object can contain the values of tags and object lengths Amount, Authorized (Binary) (Tag '81') and Terminal Type (Tag '9F35'), which represent, respectively, the size of the transaction amount and the type of terminal in which the card is serviced. In this case, the structure of the PDOL data object is shown in Fig. 3.4. PDOL data is communicated by the terminal to the card in the data field of the GET PROCESSING OPTIONS command (see section 3.10). Having received the necessary data, depending on their value, the card has the ability, in response to the GET PROCESSING OPTIONS command, to tell the terminal what data it should read on the card and which Application Interchange Profile the card has chosen to perform the current operation.
TagO = 9F38 I Length 0 = 5 bytes I Value 0 I
-----------------4
Length 0 = 5 bytes
- 4
Amount, Authorized (binary) Terminal Type
Rice. 3.4. PDOL example
In this example, we will assume that the terminal has the "Online Only" type (that is, we are talking about a terminal in which all operations are performed in real time). In this case, the card can return the Application Interchange Profile data object to the terminal, in which the 'Terminal Risk Management is to be supported' bit is equal to 0. This means that the terminal in this case should not perform the procedures for checking the Floor Limit values and other offline limits for this operations because the operation will be processed online.
In addition, in this case, the Application Interchange Profile bits corresponding to all three offline authentication methods can also be set to 0. This means that offline authentication of the card application does not need to be performed during the current transaction.
As another example, we can cite the case when, for a small size of the transaction amount, the card returns the Application Interchange Profile data object to the terminal, in which the 'Card Verification Method is supported' bit is not set, that is, it is equal to 0. This means that in this case the terminal will not perform cardholder verification. On the one hand, due to the small size of the transaction, the risks associated with the lack of verification of the cardholder are acceptable for the card issuer. On the other hand, refusal to verify the cardholder leads to simplification of transaction processing, which in many cases (for example, in fast food outlets, when paying for travel, etc.) is a prerequisite for making non-cash payments.
The FCI Issuer Discretionary Data (Tag 'BFOC') is optional and contains information as defined by the card issuer. This can be reference information such as the card manufacturer's identifier, the type of chip, the version of the operating system used, and the card mask.
Another possibility is to use the FCI Issuer Discretionary Data to implement special non-standard functions. For example, special terminals can be used to implement administrative commands to change some of the card application data. In order for the terminal to receive the right to perform an administrative operation, it must be authenticated by the card. For this, a secret key known to the card and the terminal can be used. The key ID can be stored on the card in the FCI Issuer Discretionary Data.
In the EMV file system, DF files come in two flavors: DDF (Directory Definition File) and ADF (Application Definition File).
The ADF file corresponds to a separate card application and contains (is an access point) only elementary AEF (Application Elementary File) files that store the data of this application. Internally, the ADF is selected by its SFI ID, which ranges from 1 to 30. After the ADF is selected, the SFI ID is used as an input parameter to the command that manipulates the AEF data.
Each application on the card must have its own Application ID (AID) used as the name or the beginning of the DF Name of the ADF file. Application ID can be registered (in ISO) or unregistered (private).
According to the ISO 7816-5 standard, the registered application identifier AID is encoded up to 16 bytes. The identifier consists of two parts AID = RID || PIX, where RID is a Registered Application ID of 5 bytes, PIX is a Proprietary Application Extension of up to 11 bytes.
RID is registered with ISO. For example, the corresponding RID value for all VISA AOOOOOOOOZ applications, and A000000004'h for MasterCard applications. Thus, the RID in the application identifier identifies the payment system.
The PIX values identify a specific card product for each registered RID. Listed below are examples of PIX values set by VISA and MasterCard for some of their applications.
| RID = A000000003 | |
| 1010 | VISA debit / credit |
| 2010 | VISA Electron |
| Zoyu | Interlink |
| 8010 | Plus |
| 999910 | Proprietary ATM |
| RID = A000000004 | |
| 1010 | MC credit card |
| 6000 | Cirrus |
| 3060 | Maestro |
A DDF file consists of ADF files and DDF files. Each DDF file is also selected in the card file system by its name. The criteria by which ADF files are combined (grouped) in a DDF file can vary. For example, one criterion might be the general nature of the applications that match the ADF files of the same DDF file. In particular, the DDF file that integrates payment applications is called the Payment System Environment (PSE). The name 1PAY.SYS.DDF01 is reserved for this DDF file. Chapter 7 introduces a DDF file named 2PAY.SYS.DDF01 that contains all of the card's contactless payment applications.
Another criterion for combining ADF files can be the belonging of the corresponding applications to one or another payment system operator (for example, VISA or MasterCard).
Each ADF and DDF file has an FCI Template Data Item (Tag '6F') containing those FCI header data objects that are returned to the terminal in response to a file select command. The content of the FCI Template is different for ADF and DDF files.
The FCI Template structure for the ADF file is shown in Fig. 3.3.
As seen from Fig. 3.3, the FCI Template for the ADF file consists of two required data objects:
- the DF Name (Tag '84') of the ADF file, which is called the ADF Name (Tag '4F'). The data field of the ADF Name object is either equal to the AID of the application whose data is stored in the ADF file, or starts with the AID. AID value encoded binary Tag 6F - FCI Template (M)
- ---? Tad 84 - DF Name (M)
- ---? Tag А5 - FCI Proprietary Template (М)
- ----? Tag 50 - Application Label (M)
- ----? Tag 87 - Application Priority Indicator (0)
- ---? Tag 9F38 - POOL (0)
- ---? Tag 5F0D - Language Preference (0)
- ----? Tag 9F11 - Issuer Code Table Index (0)
- ----? Tag 9F12 - Application Preferred Name (0)
- ----? Tag BFOC - FCI Issuer Discretionary Data (0)
a string (binary format of a data item) with a size of 5 to 16 bytes;
• FCI Proprietary Template (Tag'A5 '), which defines the application parameters required for the terminal to select the application, and for the card to process the transaction.
Let's dwell on the FCI Proprietary Template data object in more detail. It consists of objects presented in table. 3.7.
Tab. 3.7. FCI Proprietary Template Data Object for ADF File
| Tag | Data object content | Obligation of data object |
| '50'h | Application Label (product name) | Mandatory |
| '87'h | Application Priority Indicator | Optional |
| '9F38'h | PDOL | Optional |
| '5F2D'h | Language Preference (indicator of language preferences) | Optional |
| '9Fll'h | Issuer Code Table Index (encoding to display the Application Preferred Name object) | Conditionally optional |
| '9F12'h | Application Preferred Name | Optional |
| 'BFOC'h | FCI Issuer Discretionary Data | Optional |
The Application Label Data Object (Tag '50') is the only required element of the FCI Proprietary Template. It defines the name of the payment product corresponding to this application (for example,
MasterCard
^? 9
Maestro, Cirrus, Electron), registered by the payment system as a trademark of the card product. The Application Label Data Item is in alphanumeric format and contains one to 16 characters (format defined in ISO 7816-5). The Application Label object is designed to present the card product to the cardholder in the human-machine interface (on the terminal display) when using the card in the payment system terminal.
The Application Preferred Name data object (Tag '9F12') is optional and defines an additional name of the card product to the Application Label. The Application Preferred Name data element is represented as a string of alphanumeric characters, ranging from 1 to 16 characters, and is used as an additional identifier for the application in the HMI when the card is used in the payment system terminal. The Application Preferred Name object is introduced by the card issuer for the convenience of the cardholder. Typically, this data element is the product name, encoded only in the alphabetical encoding of the cardholder's country.
The Issuer Code Table Index data object (Tag '9F11') is optional and, according to ISO 8859, defines the alphabet encoding table used to display the Application Preferred Name string. In the case where the Application Preferred Name data object is present in the FCI Proprietary Template, the Issuer Code Table Index object is required.
The Language Preference data object (Tag '5F2D') is optional and defines from one to four languages, which, from the point of view of the issuer, are the most preferable for the dialogue between the cardholder and the terminal during the operation. Each language is encoded with two letters of the Latin alphabet in accordance with the ISO 693 standard. Two bytes are used to encode one language, so in general the length of the Language Preference data object varies from 2 to 8 bytes. The language codes in the data field of the Language Preference object are listed in descending order of priority for their respective languages.
For dialogue with the cardholder, the terminal selects the highest priority language from the list of languages of the Language Preference object supported by the terminal. If the terminal does not support any of the languages listed in the Language Preference object, the Language Preference object is ignored by the terminal.
The Application Priority Indicator data object (Tag '87') is optional and defines the order in which card applications are displayed on the POS display. The Application Priority Indicator data item is in binary format and encoded in a 1 byte string.
Bits b4, b3, b2, b of the Application Priority Indicator byte determine the value of the priority of the application. The highest priority is 1, the lowest is 15. A value of 0 means the application has no priority.
Bit b8 determines whether cardholder confirmation is required when selecting an application (b8 = 1) or not (b8 - 0). If b8 = 1, the terminal must ask the cardholder for confirmation of his consent to use this application to complete the transaction.
The PDOL data object (Processing Options Data Object List) (Tag '9F38') is optional and defines the transaction and terminal data required by the card in order to decide on the best way of processing the transaction from the point of view of the card issuer (choosing a processing "profile" transactions). The PDOL data item contains a list of tags and data object lengths required by the card (at the discretion of the issuer) to select a "profile" for processing a transaction.
Let us explain what has been said with a few examples. The PDOL object can contain the values of tags and object lengths Amount, Authorized (Binary) (Tag '81') and Terminal Type (Tag '9F35'), which represent, respectively, the size of the transaction amount and the type of terminal in which the card is serviced. In this case, the structure of the PDOL data object is shown in Fig. 3.4. PDOL data is communicated by the terminal to the card in the data field of the GET PROCESSING OPTIONS command (see section 3.10). Having received the necessary data, depending on their value, the card has the ability, in response to the GET PROCESSING OPTIONS command, to tell the terminal what data it should read on the card and which Application Interchange Profile the card has chosen to perform the current operation.
TagO = 9F38 I Length 0 = 5 bytes I Value 0 I
-----------------4
Length 0 = 5 bytes
- 4
Amount, Authorized (binary) Terminal Type
Rice. 3.4. PDOL example
In this example, we will assume that the terminal has the "Online Only" type (that is, we are talking about a terminal in which all operations are performed in real time). In this case, the card can return the Application Interchange Profile data object to the terminal, in which the 'Terminal Risk Management is to be supported' bit is equal to 0. This means that the terminal in this case should not perform the procedures for checking the Floor Limit values and other offline limits for this operations because the operation will be processed online.
In addition, in this case, the Application Interchange Profile bits corresponding to all three offline authentication methods can also be set to 0. This means that offline authentication of the card application does not need to be performed during the current transaction.
As another example, we can cite the case when, for a small size of the transaction amount, the card returns the Application Interchange Profile data object to the terminal, in which the 'Card Verification Method is supported' bit is not set, that is, it is equal to 0. This means that in this case the terminal will not perform cardholder verification. On the one hand, due to the small size of the transaction, the risks associated with the lack of verification of the cardholder are acceptable for the card issuer. On the other hand, refusal to verify the cardholder leads to simplification of transaction processing, which in many cases (for example, in fast food outlets, when paying for travel, etc.) is a prerequisite for making non-cash payments.
The FCI Issuer Discretionary Data (Tag 'BFOC') is optional and contains information as defined by the card issuer. This can be reference information such as the card manufacturer's identifier, the type of chip, the version of the operating system used, and the card mask.
Another possibility is to use the FCI Issuer Discretionary Data to implement special non-standard functions. For example, special terminals can be used to implement administrative commands to change some of the card application data. In order for the terminal to receive the right to perform an administrative operation, it must be authenticated by the card. For this, a secret key known to the card and the terminal can be used. The key ID can be stored on the card in the FCI Issuer Discretionary Data.
