The architecture model used by Agnos Framework lies on a 3-tiers structuration. For convenience, let's map each tier to an EMV semantic level:

• Tiers1 ≅ EMV Level1: level covering all platform related services. It includes card coupling (CT and CL)

• Tiers2 ≅ EMV Level2: level covering card processing services. It covers EMVCo L2 CT , EMVCo L2 CL, and payment networks' CL specifications

• Tiers3 ≅ EMV Level3: level covering payment services. It covers all applications or libraries providing services to sales systems, or using services from TMS, or acquirer/processing systems

Tiers1 - EMV Level1

See GPI page.

Agnos Framework runs on top of a HAL, the GPI interface (see release notes or gpi.c for versioning). Depending on the platform’s constraints, a GPI may have different structures (single static lib, single dynamic lib, one or more dynamic lib, client/server architecture, etc…). However, it always provides the same API to higher abstraction levels (i.e. Level2 and Level3).

The most important aspect to take into account before adapting a GPI to a new platform is the hardware security architecture. Does the platform use a single or 2 processors (i.e. 1 applicative chip + 1 secured chip)? How PCI constraints will be supported?

The GPI implementation should be performed in the following order:

• Platform: file system, or flash read/write integration

• Platform: RTC integration

• SPED: display and strings tables integration (basic mechanisms in order to manage minimum text displays)

• SPED: depending on the needs, basic mechanisms integration in order to manage user key entries (like cardholder selections)

• CAD: depending on the needs, contact/contactless/swipe integration

• SPED: depending on the needs, integration of an external graphical library (for example, an EPP at an ATM)

• SPED: secure online/offline pin entry integration

• Platform: S/N, sleep, beep, sound, …

• HSM: depending on the needs, clippping and SRED integration, unpredictable number, …

It may require between 4 and 10 weeks to implement a new GPI and to qualify it. Refer to [1] for more details.

Then, performance constraints must also be considered early in the project when working on the Level1 part. Contactless projects brings new level of constraints that shall be anticipated.

Finally, acquirer/processor requirements are to be foreseen also. They are not part of the EMV specifications. The features covering that topic are beyond Agnos. Hence, these functions are included into the xGPI:

• Key loading to support MAC, ONLINE PIN encryption, END-TO_END encryption and more depending on the deployment region

• Master/Session or DUKPT key management

• SSL to support secure transportation

• AES to support Transportation requirements related to Data Storage

It may require between 4 and 10 weeks to implement and to test the features related to xGPI.

Tiers2 - EMV Level2

See AGNOS page
See AGNOSEP page

Agnos Framework L2's core includes Agnos and AgnosDB. These parts of the package have been certified against EMVCo latest specifications. Agnos and AgnosDB are systematically tested against different contact ICS.

By extension, contactless kernels (or librairies) are also considered as part of the system's Level2 layer. Hence, Agnos entry point is also part of the L2 layer. These components have been certified against EMVCo and/or payment networks latest specifications.

As soon as a first GPI version is available, there is no actual L2 integration in regards with EMV functional features. The only aspects to address are:

• Compilation options aligned on projects requirements and RAM constraints (see Symbols, options, and constants)

• Physical model to deploy (i.e what are the units of compilation)

• Performance, and platform integration requirements (fallback to other interface(s), displays, UX, …) (see Qualification Knowledge Base)

Tiers3 - EMV Level3

See AGNOSMW page.

Level3 includes AgnosMW, optionally AgnosGE, and a sample code Kizis including transaction triggering, configuration management, EMV initiation/completion pattern and an EMVCo payment application used for EMVCo contact Level2 certification. The main steps to follow while integrating Agnos are:

⇒ What are the payment brands to support and the card interfaces to support?

• To validate whether contact and contactless interfaces are required for each brand?

• To validate whether or not different contact payment applications are required?

⇒ What are the ICS required for the project?

• To validate that the specific TMS data model (backing Agnos) supports them

• To validate that Agnos supports them

⇒ What are the merchant requirements?

• Who enter/validate the amount? When?

• Is there a TIP?

• What are the UI requirements when a card is not removed? A card is mute? A chip card is swiped?

• Does the Level3 support fallbacks? How?

• Are there any performance constraints to be considered like card removal at opening gates?

• How many languages are supported?

• How does a merchant trig a transaction: from a cash register? from a device resident software component?

• Is there any logical/physical separation to be implemented to support certification constraints?

• Are there any offline acceptance cases when terminal is unable to go online? How does the terminal manage them in a secure way?

• What is the receipt format? Which EMV parameters shall be used according regional rules?

⇒ What is the processor context for the project?

• To validate the security scheme (DUKPT? Master/Session? Key Loading? …)

• To validate the processor protocol (ISO8583? SPDH? EPAS/Nexo Acquirer? …)

• To validate the transport layer (TCP/IP? TCP/IP/SSL?);

• To validate the configuration protocol and related parameters (integrated in processor protocol or not? EPAS TMS?)

• To understand how to configure Agnos from a specific TMS data model

⇒ Are there any regional specifications

• EMV selection rules like in Canada or US

• Quick Chip like in US

• Amount validation at PIN entry

See Logical Model page.