Introduction

That section presents how different abstractions related to the system’s configuration are linked all together. These abstractions are usually part of a TMS system and downloaded onto the point of acceptance, i.e. the terminal running Agnos. There are different perspectives attached to a data model:

1. The transportation model

2. The persistent model

3. The instantiated model

Transportation Model

The transportation model is not presented because it’s specific to the infrastructure integrating Agnos. Depending on the acquirer/processor TMS system, the data model may be transported using XML files, a series of protocol messages (like NEXO TMS or ISO8583), or even proprietary structures (there might be no model at all).

Persistent Model

The persistent model is specific to Agnos. It’s important to learn that model because it’s used by the framework to get ready to process transactions. That model is built from the transportation data and stored onto the terminal. From Agnos Framework 2.x.x, there are 2 persistent models:

1. The legacy RAW files including TERMINAL, PROCESSING, ENTRY_POINT, AID, and COMBINATION. The structures of these files are documented in Appendixes.

2. The TLV files including TERMINAL, PROCESSING, and ENTRY_POINT. The structures of these files are documented in Appendixes.

Note1: Agnos Framework architecture uses the same data model as for ACE (client and server parts). ACE is optional to develop and to certify Agnos applications. But, the transportation layer (ACE2P protocol) that is used maps the persistent model to ease the integration.

Note2: Knowing ACE2P, ACE may be used without Agnos to certify any EMV stacks on any terminal. This allows a terminal to fetch configuration data required for certification sessions (CAPK, list of AIDs and underlying parameters …).

Instantiated Model

The instantiated model is the logical view of the system’s configuration. It can be found in datamngr.h (i.e. AgnosMW library. Once RAW/TLV files are loaded, i.e when Level3 has called an initialization service, RAW/TLV data are used to set the actual Agnos Framework model that is used at running time and lives in RAM.

Note: If a L3 Application uses OLA, the persistent model depends on the payment application. In the other words, the way to store the configuration data is the responsibility of the integrators. As a reference, Agnos uses the following values for data configuration:

Data Model

Agnos Framework supports both contact and contactless transactions. The difference between the configuration paradigms is:

• In contact (acronyms K or CT), configurations are AID driven. There are 2 files: TERMINAL (RAW or TLV format), and PROCESSING (RAW or TLV format)

• In contactless (acronym CL), configurations are KAT driven. KAT stands for Kernel Id / AID Id / Transaction Type id. There are 5 files: TERMINAL (RAW or TLV format), PROCESSING (RAW or TLV format), ENTRY_POINT (RAW or TLV format), SUPPORTED AID (RAW format only), COMBINATION (RAW format only), and UPDATE CONDITIONS (TLV format)

Open

For more details, see:

• TERMINAL

• PROCESSING

• ENTRY POINT

• SUPPORTED_AID (Deprecated)

• COMBINATION (Deprecated)

• UPDATE CONDITIONS (where <update conditions> ::= UC + '_' + 'C' + <kernel id>)

Contact Kernel Settings

Conctact configurations are managed from a list of AID. Each AID comes along with a set of EMV parameters.

Contactless Kernels Settings

Conctactless configurations are made of combinations. Each combination is uniquely identified thanks to a primary called a KAT key:

• K standing for Kernel Identifier

• A standing for Aid Identifier

• T standing for Transaction Type

Here is the mapping between the kernel labels and identifiers supported by Agnos Framework:

Note: Agnos Framework supports up to 255 kernel identifiers to comply with EMVCo Book B certification requirements.

Here is the mapping between the AID and identifiers supported by Agnos Framework:

Here is the mapping between the transaction type and identifiers supported by Agnos Framework (see paymentMW.h and tTransactionType enumeration type):

INI File Management

The persistent model may be generated using INI files. See INI File Management page.