Väljaminev kiri

Annex 2

Technical Requirements

2

CONTENTS

1 INTRODUCTION ............................................................................................................................................................................................................... 6

1.1 SCOPE OF TENDER .................................................................................................................................................................................................. 6

1.2 REQUIREMENTS STRUCTURE .............................................................................................................................................................................. 7

1.3 TERMINOLOGY ........................................................................................................................................................................................................ 7

1.4 DEFINITIONS AND ABBREVIATIONS ................................................................................................................................................................... 8

1.4.1 DEFINITIONS ..................................................................................................................................................................................................... 8

1.4.2 ABBREVIATIONS .............................................................................................................................................................................................. 9

1.5 REFERENCES AND STANDARDS ........................................................................................................................................................................ 10

3

2 GENERAL REQUIREMENTS ......................................................................................................................................................................................... 14

2.1 REQUESTED SOLUTION ....................................................................................................................................................................................... 15

2.1.1 DOCUMENT READER .................................................................................................................................................................................... 16

2.1.2 SDK .................................................................................................................................................................................................................... 16

2.1.3 EXISTING INSPECTION APPLICATION ...................................................................................................................................................... 16

2.1.4 CONFORMITY ................................................................................................................................................................................................. 16

2.2 DOCUMENT VERIFICATION DATA ..................................................................................................................................................................... 17

2.3 SYSTEM DOCUMENTATION................................................................................................................................................................................. 17

3 REQUIREMENTS TO DOCUMENT READERS ........................................................................................................................................................... 17

3.1 TECHNICAL REQUIREMENTS ............................................................................................................................................................................. 17

3.1.1 DOCUMENT FORMATS .................................................................................................................................................................................. 18

3.1.2 READING THE OPTICAL DATA .................................................................................................................................................................... 18

3.1.3 SUPPORTED IMAGE/CAMERA RESOLUTION ........................................................................................................................................... 21

3.1.4 SUPPORTED CODE PAGES BY OCR ............................................................................................................................................................ 21

3.1.5 RFID CHIP READER ........................................................................................................................................................................................ 21

3.1.6 NETWORK INTERFACES ............................................................................................................................................................................... 22

3.1.7 DOCUMENT READER CERTIFICATION...................................................................................................................................................... 23

3.1.8 PERFORMANCE CAPABILITIES AND TEMPORAL REQUIREMENTS ................................................................................................... 23

3.1.9 COMMUNICATION REQUIREMENTS FOR THE RF-READING MODULE ............................................................................................ 23

3.1.10 DOCUMENT MODEL DATABASE SUPPORT .............................................................................................................................................. 23

3.1.11 CHIP APPLICATION SUPPORT ...................................................................................................................................................................... 24

3.1.12 AUTOMATION REQUIREMENTS ................................................................................................................................................................. 24

4

3.1.13 DIGITAL TRAVEL DOCUMENT HANDLING REQUIREMENTS .............................................................................................................. 25

3.1.14 OPERATING CONDITIONS ............................................................................................................................................................................ 25

3.1.15 VARIA ............................................................................................................................................................................................................... 25

4 VERIFICATION OF MRTDS ........................................................................................................................................................................................... 26

4.1 PROCESS SEQUENCE OF CHECKING A MRTD ................................................................................................................................................. 26

4.2 ERROR CODES ........................................................................................................................................................................................................ 27

4.3 OPTICAL CHECKS OF MRTDS ............................................................................................................................................................................. 29

4.3.1 DOCUMENT MODEL ...................................................................................................................................................................................... 29

4.3.2 SPECTRALLY SELECTIVE CHECK ROUTINES ......................................................................................................................................... 29

4.3.3 CATALOGUE FOR SPECTRALLY SELECTIVE CHECKS .......................................................................................................................... 31

4.4 DOCUMENT MODEL IDENTIFICATION ............................................................................................................................................................. 32

4.5 DOCUMENT AUTHENTICITY VERIFICATION .................................................................................................................................................. 33

4.5.1 CHECKING THE MRZ CONSISTENCY ........................................................................................................................................................ 33

4.5.2 SPECTRALLY SELECTIVE VERIFCATION ................................................................................................................................................. 33

4.5.3 CROSS VERIFICATION OF DATA ................................................................................................................................................................. 33

4.6 ELECTRONIC CHECKS OF ELECTRONIC MRTDS ........................................................................................................................................... 34

4.6.1 SUPPORT OF THE FOLLOWING PROTOCOLS AND SECURITY MECHANISMS ................................................................................. 34

4.6.2 FILES AND DATA GROUPS TO BE READ ................................................................................................................................................... 35

4.6.3 PROCESSING SEQUENCES ........................................................................................................................................................................... 36

4.6.4 CHIP ACCESS VIA BAC OR PACE ................................................................................................................................................................ 36

4.6.5 CHECKING THE CHIP AUTHENTICITY (AA, CA) ..................................................................................................................................... 36

4.6.6 VERIFICATION OF THE SECURITY OBJECTS ........................................................................................................................................... 36

5

4.6.7 CHECKING ISSUER CERTIFICATES ............................................................................................................................................................ 37

4.6.8 INTEGRITY OF CHIP CONTENTS ................................................................................................................................................................ 37

4.6.9 INTEGRITY OF DOCUMENT CONTENTS ................................................................................................................................................... 38

5 REQUIREMENTS DEFINITION AND TENDER EVALUATION ................................................................................................................................ 38

5.1 REQUIREMENTS DEFINITION ............................................................................................................................................................................. 38

5.1.1 MINIMUM REQUIREMENTS ......................................................................................................................................................................... 38

FIGURES

Figure 1. Schematic description of the requested solution

Figure 2. Process sequence of checking MRTDs

Figure 3. Process of optical checks of MRTDs

TABLES

Table 1: Scope of Tender

Table 2: Interpretation of keywords

Table 3: Definitions

Table 4: Abbreviations

Table 5: References

Table 6: Matrix representation of the generic basic check routines.

6

1 INTRODUCTION

It is recommended to deal with the definitions and descriptions as described in “Machine Readable Travel Documents” [ICAO9303], FRONTEX “Best

Practice Technical Guidelines for Automated Border Control (ABC) Systems”, “Best Practice Operational Guidelines for Automated Border Control (ABC)

Systems” as well as in the ICAO “Technical Report on Machine Assisted Document Security Verification”. Regarding modern electronic Identity Documents

the Technical Guidelines [TR-03127] and [TR-03110] are recommended.

The document readers must be capable to provide input to satisfy the requirements provided in this document for processing data in the Inspection System

even if the processing is not taking place / cannot be applied directly to the reader device.

1.1 SCOPE OF TENDER

Table 1 describes the scope of this tender. Refer to Chapter 2 for further description of each component.

Solution component Scope

Document model database The Vendor SHALL deliver document model database which copies

will be installed in the IS workstations.

Document Reader Provider

for Secunet Biomiddle

version 3.2x or later.

If the solution provided does not have the Reader Provider module

by Secunet the Vendor SHALL supply the module together with

corresponding license.

Document readers Readers capable of processing all [ICAODOC] and [ISO/IEC 18013-

1] compatible identity and travel documents.

Licenses The Vendor SHALL submit all the licenses required to operate the

document reader and Document model database. Licenses MUST

cover all the document readers purchased in course of this Tender.

Support The Vendor will provide full support and warranty service of the

delivered hard- and software, including the Database, for 3 years.

The Vendor SHALL provide updates to the Database at least once

per 2 months.

7

SDK The Vendor SHALL deliver SDK together with the document

readers.

Table 1: Scope of Tender

The requested software, hardware and related licenses MUST cover all different environments – live, testing, development etc. Every reader MUST be able

to be operated in these environments.

1.2 REQUIREMENTS STRUCTURE

Chapter 2 contains overall requirements.

Chapter 3 contains technical requirements to the reader devices.

Chapter 4 contains requirements to the procedures of document reading and verification process.

1.3 TERMINOLOGY

Requirements as defined in this Specification can be mandatory, recommended or optional. All the requirements in this document are mandatory if not

otherwise clearly specified.

MUST, SHALL,

REQUIRED, NORMATIVE

The implementation is an absolute requirement of the

specification and must be used/included.

RECOMMENDED, NOT

RECOMMENDED,

SHOULD, SHOULD NOT

The requirements are recommendations, this means that there

may exist valid reasons in particular circumstances to ignore a

particular item or requirement, but the full implications must be

understood and carefully weighed before choosing a different

course.

MAY, OPTIONAL The requirements are not binding. One operator or vendor may

choose to include it, another may omit it.

MUST NOT, SHALL NOT A so-called requirement is an absolute prohibition of the

specification.

Table 2: Interpretation of keywords

8

1.4 DEFINITIONS AND ABBREVIATIONS

1.4.1 DEFINITIONS

Term Definition

Contracting Authority The term Contracting Authority is used to refer to IT and Development

Centre, Ministry of the Interior (SMIT) as responsible for the tender

process and as responsible Commissioning Party.

EAC-PKI Extended Access Control Public Key Infrastructure – The

infrastructure required to control read access to fingerprint biometrics

on Passports and Travel Documents through Extended Access Control.

MRTD Term used to encompass all Machine Readable Travel Documents.

eMRTD Term used to encompass all electronic Machine Readable Travel

Documents, hereunder electronic Passports, Residence Permits, Local

Border Traffic Permits and National Identity Cards.

Inspection System In the scope of the present tender the system containing document

reading SDK, Secunet Biomiddle module and user interface to display

information to the operator. Inspection System gets its input data from

a full-page flatbed document reader and Contracting Authority’s

backoffice services and databases.

Terminal Inspection System (IS) as defined in [BSI_TR_03110_1] p.2.2.

Travel Document An identity document compliant to [ICAO9303] and acknowledged as

such due to [ICAO9303] or international agreements.

9

Operator Term is used to cover all human personnel that require system access

to operate, administer, or audit the Inspection System and document

reader.

Vendor The term is used throughout this specification to refer to the vendor,

tenderer/bidder or contractor in all phases of the procurement and

delivery of the requested solution.

Table 3: Definitions

1.4.2 ABBREVIATIONS

CA Certification Authority

CRL Certificate Revocation List

CSCA Country Signing Certification Authority

CS-PKI Country Signing Public Key Infrastructure

CVCA Country Verifying Certification Authority

EAC Extended Access Control

ECC Elliptic Curve Cryptography

e-DL Electronic driver’s license

e-ID Electronic identity document

eMRTD Electronic Machine Readable Travel

Document

ePass Electronic Passport

10

eRP Electronic Residence Permit

ICAO International Civil Aviation Organisation

IS Inspection System

MRTD Machine-Readable Travel Document

PA Passive Authentication

PKI Public Key Infrastructure

SOD Document Security Object

TA Terminal Authentication

RSA Rivest Shamir Adleman

SHA Secure Hash Algorithm

DTC Digital Travel Credentials

DTC-VC Digital Travel Credentials Virtual Component

DTC-PC Digital Travel Credentials Physical

Component

Table 4: Abbreviations

1.5 REFERENCES AND STANDARDS

# Standard Publisher Date

11

[ANSI X9.142] ANSI X9.142-2020 Public

Public Key Cryptography for the Financial

Services Industry —

The Elliptic Curve Digital Signature

Algorithm ECDSA.

ANSI Sep. 10th,

2020

[BSI_TR_03105-4] Bundesamt für Sicherheit in der

Informationstechnik, Technical Guideline

TR-03105 Part 4. Test Plan for ICAO-

compliant Proximity Coupling Devices

(PCD) on Layers 1-4, version 3

BSI 2016-11-

04

[BSI_TR_03105_5-1] Bundesamt für Sicherheit in der

Informationstechnik, Technical Guideline

TR-03105 Part 5.1, version 1.5: Test plan

for ICAO compliant Inspection Systems

with EACv1

BSI February

10th, 2020

# Standard Publisher Date

[BSI_TR_03105_5-2] Bundesamt für Sicherheit in der

Informationstechnik, Technical Guideline

TR-03105 version 1.2, Conformity Tests for

Official Electronic ID Documents, Part 5.2,

version 1.2 Test plan for eID and eSign

compliant eCard reader systems with EAC

2

BSI 2013-11-19

12

[BSI_TR_03110_1] Bundesamt für Sicherheit in der

Informationstechnik, Technical Guideline

TR-03110-1 version 2.10, Advanced

Security Mechanisms for Machine

Readable Travel Documents – Part 1 -

eMRTDs with BAC/PACEv2 and EACv1.

BSI March

20th, 2012

[BSI_TR_03110_3] Bundesamt für Sicherheit in der

Informationstechnik, Technical Guideline

TR-03110-3 version 2.10, Advanced

Security Mechanisms for Machine

Readable Travel Documents – Part 3 –

Common Specifications

BSI March

20th, 2012

[BSI_TR_03127] Bundesamt für Sicherheit in der

Informationstechnik, Technical Guideline

TR-03127 version 1.13, Architecture

electronic Identity Card and electronic

Resident Permit

BSI March

10th, 2011

[BSI-TR-03135-1-v2-5] Bundesamt für Sicherheit in der

Informationstechnik, Technical Guideline

TR-03135 - Machine Authentication of

MRTDs for Public Sector Applications Part

1: Overview and Functional Requirements

BSI 2023

13

[BSI-TR-03135-2-v2-5] Bundesamt für Sicherheit in der

Informationstechnik, Technical Guideline

TR-03135 - Machine Authentication of

MRTDs for Public Sector Applications Part

2: Application profiles for official

document inspection systems

BSI 2023

[BSI-TR-03135-3-v2-5] Bundesamt für Sicherheit in der

Informationstechnik, Technical Guideline

TR-03135 - Machine Authentication of

MRTDs for Public Sector Applications Part

3: High Level Document Check Interface

Specification

BSI 2023

[EN 62368-1:2024] IEC/EN 62368-1:2024: Audio/video,

information and communication technology

equipment. Safety requirements.

IEC/EN 2024

[ICAO9303] Doc 9303 Machine Readable Travel

Documents, Eight Edition, Parts 1 – 13

ICAO 2021

# Standard Publisher Date

[IEC 62471] IEC 62471-6:2023: Photobiological safety

of lamps and lamp systems

2023

[ISO_1831] ISO 1831: Printing specifications for

optical character recognition

ISO

14

[ISO10918-1] ISO/IEC 10918-1: Information technology

- Digital compression and coding of

continuous-tone still images:

Requirements and guidelines

[ISO/IEC 18013] ISO/IEC 18013: Information technology -

Personal identification - ISO-compliant

driving licence – a set of standards.

ISO/IEC

[RFC_4122] RFC 4122: A UUID URN Namespace IETF July 2005

[RFC 5639] RFC 5639: Elliptic Curve Cryptography

(ECC) Brainpool Standard Curves and

Curve Generation

IETF March

2010

Table 5: References

2 GENERAL REQUIREMENTS

Each MRTD MUST be assigned to a document model according [BSI-TR-03135-1-v2-5] p.

5.5.1.1

15

2.1 REQUESTED SOLUTION

Figure 1. Schematic description of the requested solution

The Contracting Authority intends through this tender to update the currently deployed identity and travel document verification infrastructure. At the same

time, the Contracting Authority intends to acquire an enhanced solution providing more advanced services for Inspection Systems together than today.

Figure 1 provides a schematic overview of the requested solution. The figure serves the purpose of functional specification and scoping only. The Contracting

Authority accepts that the naming of systems or components of the Vendor’s offered solution may differ from the naming used in this document. The

Contracting Authority also accepts that the Vendor’s solution might be implemented in such a way that systems or system components are combined or

linked in a different manner than reflected in Figure 1.

A more detailed description of each functional component in Figure 1 is provided in the following sub-chapters.

16

2.1.1 DOCUMENT READER

The document reader records the features of a given MRTD according to its type. Afterwards, the document reader transmits this data to an Inspection

Application for further processing.

The document readers MUST be standalone stationary models for indoor use.

2.1.2 SDK

The role of SDK is:

to manage mapping of the read document to a document model in the model database; and manage data exchange between document reader and Secunet

BioMiddle environment.

2.1.3 EXISTING INSPECTION APPLICATION

The Inspection System contains Secunet Biomiddle services that control the reading process of the document reader, processes the information and MRTD

features obtained by it.

2.1.4 CONFORMITY

All components supplied by the Vendor SHALL make it possible for the Inspection System and Inspection Application to completely implement and meet

all requirements from chapters 4.2.3 of [BSI-TR-03135-2-v2-5] for the Stationary application scenario.

17

2.2 DOCUMENT VERIFICATION DATA

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 1.

Document reader and SDK SHALL be able to provide all the document verification data in a format

that is sufficient to build [BSI-TR-03135-1-v2-5] compatible transaction log, according to XML

schemas provided in [BSI-TR-03135-XML, v2.5]. Transaction log MUST contain all data obtained in

the process of document verification process.

2.3 SYSTEM DOCUMENTATION

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 2.

General System Documentation

The Vendor SHALL, for all software and equipment (hardware) offered, provide general system

documentation written in English covering the following topics:

• “Maintenance Guide of the document readers” containing instructions of cleaning, calibration

etc. targeting personnel responsible for installation, configuration and maintenance.

• “Programmers Guide” targeting personnel responsible for system integration/customization,

e.g. if software is provided with SDKs/APIs.

3 REQUIREMENTS TO DOCUMENT READERS

3.1 TECHNICAL REQUIREMENTS

1. MRZ quick Scan

2. Full (data)page full resolution scan

3. Chip

18

3.1.1 DOCUMENT FORMATS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 3. Document reader type: full-page. Swipe reading functionality of MRZ MUST NOT be present.

REQ 4. Document reader supports TD1 format of MRTDs specified in [ICAO9303]

REQ 5. Document reader supports TD2 format of MRTDs specified in [ICAO9303]

REQ 6. Document reader supports TD3 format of MRTDs specified in [ICAO9303]

REQ 7. Document reader supports MRVA format of MRTDs specified in [ICAO9303]

REQ 8. Document reader supports MRVB format of MRTDs specified in [ICAO9303]

REQ 9. Document reader supports documents not compatible to [ICAO9303] up to scanning area size ≥ 87*125

mm

3.1.2 READING THE OPTICAL DATA

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 10. Reading of VIZ, MRZ and CAN MUST be supported.

REQ 11. Recording of images in 365 nm UV, visible and near IR (B900) spectral ranges MUST be supported.

REQ 12.

Document reader sensitivity to incoming ambient light MUST be minimized by:

1. shielding by technical safeguarding measurements;

2. by compensating of external light; or

3. by both methods.

Requirement MUST be fulfilled at least for UV wavelength spectral range.

19

REQ 13. Glare removal from laminate and DOVIDs in visible and B900 illumination spectral range MUST be

supported.

REQ 14. Computer readable image file formats (PNG, TIFF and JPEG) with an image resolution of at least 450 ppi

MUST be supported when recording the data page image.

REQ 15. OCR of data in VIZ, MRZ and CAN MUST be supported.

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 16.

OCR of data MUST be based on the B-900 spectral range (IR) image. MRZ check based on the visible

light (VI) image SHALL be performed only if the OCR reading of the MRZ based on IR was not

successful.

REQ 17.

Document model identification MUST be based on spectrally selective check for identification

characteristics in VI, UV and/or IR images only in case the MRZ analysis is not sufficient for such an

identification.

REQ 18. System MUST check quality of the MRZ.

REQ 19.

Following MRZ configurations MUST be supported:

• 44*2 symbols;

• 36*2 symbols;

• 30*3 symbols; and

• 30*1 symbols.

20

REQ 20.

Automated reading of following 1D and 2D barcodes MUST be supported:

• Codabar;

• Code 128;

• Code 39 (+extended);

• Code 93;

• EAN-8;

• EAN-13;

• Interleaved 2 of 5 (ITF);

• STF (Industrial);

• Matrix 2 of 5

• IATA 2 of 5 (Airline);

• UPC-A;

• UPC-E;

• PDF-417;

• QR Code;

• Datamatrix;

• Aztec

REQ 21.

Automated reading, decoding and verification of following 2D barcodes MUST be supported:

ICAO Digital Barcode

EU Schengen Visa sticker 2D barcode

21

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 22. 2-sided reading of TD1 format of MRTDs specified in [ICAO9303] MUST be supported.

REQ 23. 2-step reading of documents1 within the same transaction MUST be supported.

3.1.3 SUPPORTED IMAGE/CAMERA RESOLUTION

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 24. Image/camera optical resolution MUST be ≥ 450 dpi / ≥ 5 Mpi

3.1.4 SUPPORTED CODE PAGES BY OCR

3.1.4.1 CODE PAGE RECOGNITION

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 25. At least CP1250, CP1251, CP1252, CP1253, CP1254, CP1257 code pages MUST be supported.

3.1.4.2 FEATURES

REQ 26. Dictionary Support MUST be present.

REQ 27. Automatic text division into separate fields MUST be supported.

REQ 28. Recognition of dates with complex formats MUST be supported.

REQ 29. Recognition of characters from different code pages in one line MUST be supported.

3.1.5 RFID CHIP READER

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

1 For example, checks across several documents (e. g. passport, visa) or document pages are possible for a given model and additional sticker (e. g. visa).

22

REQ 30. Compliance to ISO 14443 Type А and В

REQ 31. Transmission protocol T=CL MUST be supported.

REQ 32. Communication protocols Direct, BAC, SAC/PACE, ЕАС; Chip Authentication (CA v1, CA v2) and

Terminal Authentication (TA v1, TA v2) , Active and Passive Authentication MUST be supported.

REQ 33. Data exchange rates 106, 212, 424 and 848 kbps, Extended Length MUST be supported.

REQ 34. Chip detection in any part of the document MUST be supported.

REQ 35. Chip MUST be readable when document is positioned on the optical reading surface.

REQ 36. Anti-collision protocol (chip selection based on MRZ reading results) MUST be used.

REQ 37. LDS versions and eMRTD PKI defined in ICAO 9303 MUST be supported.

REQ 38. NFC Wireless Charging (NFC WLC) capability MAY supported.

3.1.6 NETWORK INTERFACES

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 39. Connection interface to the IS workstation – USB 2.02.

REQ 40. Bluetooth 6.0, including Bluetooth Low Energy (BLE) MUST be supported.

REQ 41. Power supply MUST be accomplished via connection interface to IS Workstation.

REQ 42. Supply current, max – 2 A.

2 USB 3.0 and 3.1 recommended

23

3.1.7 DOCUMENT READER CERTIFICATION

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 43. Document reader MUST have the following certifications - CE, RoHS, EN 62368-1, EN62471.

REQ 44. Document reader MUST have the following certifications - [BSI_TR_03105_4] ,[BSI_TR_03105_5-

1] and [BSI_TR_03105_5-2]

3.1.8 PERFORMANCE CAPABILITIES AND TEMPORAL REQUIREMENTS

REQ 45. Chip access process MUST start as soon as the MRZ or the CAN content becomes available.

REQ 46. Digitized records of the extracted MRZ or CAN MUST be made available to the IS in ≤ 2,5 seconds3

after the document4 has been placed onto the reader.

REQ 47. Activation of concurrent optical and electronic checks MUST take place as soon as the optical and

electronic data required for such checks are available. See Figure 2.

REQ 48. Document verification MUST start as soon as the input data becomes available to the system.

REQ 49. Full document verification process of an electronic MRTD5 SHALL NOT take longer than 7 seconds6.

3.1.9 COMMUNICATION REQUIREMENTS FOR THE RF-READING MODULE

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 50. The RF-reading module MUST be certified according to [TR-03105-4]

3.1.10 DOCUMENT MODEL DATABASE SUPPORT

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

3 Corresponds to t1 on the Figure 2. 4 Estonian passport of 2025 is used as the reference document. 5 On a reference electronic MRTD using an Inspection System operated on technology using the minimal system requirements as specified by the manufacturer. 6 Corresponds to t2 on the Figure 2.

24

REQ 47. Only local database copies installable in IS workstations applicable. No cloud service allowed.

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 51. Database MUST be updated at least once per 2 months.

REQ 52. Database MUST be updated in 2 weeks with new document data after providing relevant document

specimens by the Contracting Authority.

3.1.11 CHIP APPLICATION SUPPORT

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 53.

Applications to be supported:

e-Passport (DG01 – DG16); e-

ID (DG01 – DG21); eDL

(DG01 – DG14) ; DTC-PC

(DG01 – DG24) and LDS2

(TravelRecords, VisaRecords,

AddBiometrics)

3.1.12 AUTOMATION REQUIREMENTS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 54. Automatic document detection MUST be supported.

REQ 55. Document scanning process MUST start automatically

REQ 56. Document recognition and mapping to model database MUST take place automatically.

REQ 57. Automatic search and cropping of document image MUST be supported.

25

3.1.13 DIGITAL TRAVEL DOCUMENT HANDLING REQUIREMENTS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 58. DTC-VC attributes parsing and validation MUST be supported.

REQ 59. Creating DTC-VC from existing eMRTD data MUST be supported.

REQ 60. Full support of handling DTC-PC Type 2 and Type 3

3.1.14 OPERATING CONDITIONS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 61. Document readers MUST be able to operate at ambient temperatures 5 – 35 degrees centigrade.

3.1.15 VARIA

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 62. No moving parts allowed.

REQ 63. The working status of the document reader must be shown by LED indicator(s).

REQ 64. Document reader MUST be compliant to [EN 62368-1:2024] and [IEC 62471]

REQ 65. Document reader MUST support new DG2 data format according to ISO/IEC 39794-5

REQ 66. Document reader MUST support new DG3 data format according to ISO/IEC 39794-4

4 VERIFICATION OF MRTDS

Chapter 4 describes data processing procedures that must be accomplished during a document

check whether it takes place in the reader or in the IS workstation. If the data processing takes

place in the IS workstation the Document Reader Provider (API, see Figure 1. here above) MUST

be capable to provide corresponding data formatted according to XML-schema according to the

[TR-03135] Part 1 p. 5.2.

4.1 PROCESS SEQUENCE OF CHECKING A MRTD

Figure 2. Process sequence of checking MRTDs

Document verification MUST start automatically (time t0) with placing a document to the reader’s

reading surface. The first reading of the MRZ takes place while the document is slided towards the

final reading position. As the MRZ is read during sliding the document to its final reading position

the result of the reading will be delivered to the IS right after the successful result of OCR (time

t1). This allows to start communication between chip and the reader and thus document verification

process earlier and reduce overall time of the verification process for the holder this way increasing

throughput of persons. Time t2 indicates the end of the document checking process and making

results available for the IS.

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 67. Compatibility to the schema on Figure 2

REQ 68. Performing logical check based on data generated during optical reading

REQ 69. Performing check of the optical/physical security features of the document

4.2 ERROR CODES

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 70. Data made available for processing errors logging for optical, electronic, and combined check classes.

REQ 71. Error code MUST be in numeric integer format having value defined in the integer range of 1 – 999

999.

REQ 72. Error code for each partial check SHALL make it possible to distinguish between check classes.

Figure 3. Process of optical checks of MRTDs

4.3 OPTICAL CHECKS OF MRTDS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 73. Compatibility to the schema on Figure 3

REQ 74. Presence of barcode and contents of decoded barcode data MUST be delivered to Secunet BioMiddle

module.

REQ 75. Transliteration of characters in compliance with [ICAO9303] for comparison with MRZ MUST be

supported.

4.3.1 DOCUMENT MODEL

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 76. Each MRTD MUST be assigned to a document model (sometimes also called series) according to

[TR-03135-1] p.5.5.1.1.6

4.3.2 SPECTRALLY SELECTIVE CHECK ROUTINES

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 77. Local document model database assisting in the checking process.

REQ 78. Assignment of an unique identifier (UUID according [RFC4122]) for each generic check by the

manufacturer according to [TR-03135-1] p.5.5.1.2

6 A document model is defined by means of the country code (C), document type (T), a distinct identification number (N) and a year value (Y).

30

Feature / Area

(ZZ)

Light Source

(XX)

VI UV IR

Fibers FI LU

Full data page FU BR

Static printed

feature

IS {AB, TR} LU {AB, TR, TL}

MRZ MR AB BR AB

Overprinted MRZ OM LU

CAN CA AB AB

Personalized

perforation

(dynamic)

PD AB LU AB

Perforation of the

substrate

PS AB LU AB

Photo PH {AB, FR} {BR, FR} {AB, FR, TR}

Secondary Photo SP {AB, TR} LU {AB, TR}

Overprinted

photo

OP LU

Security thread TH TR LU AB

Visual Inspection

Zone (VIZ)

VZ BR

Watermark WM AB

31

Personalized

dynamic feature

ID {AB, TR} LU {AB, TR}

Additional feature AF {AB, BR, LU,

TL, TR}

{AB, BR, LU,

TL, TR}

{AB, BR, LU,

TL, TR}

Table 6: Matrix representation of the generic basic check routines. Used abbreviations according to the [TR-03135-1] p.5.5.1.2.

In addition, there can be the following composite check routines:

– (IR, AB, TH) in combination with (VI, TR, TH): Check that a thread visible under IR light is invisible under white light.

– (IR, TR, ID) in combination with (VI, AB, ID): Check that the ink of the dynamic print image absorbent under white light is transparent under IR light.

– (IR, TR, IS) in combination with (IR, AB, IS): Check that some parts of the static print image are absorbent under IR light, whereas other parts of the

characteristics are transparent.

– (IR, TR, IS) in combination with (VI, AB, IS): Check that the ink of the static print image absorbent under white light is transparent under IR light.

– (IR, TR, IS) in combination with (VI, AB, IS) and (IR, AB, ID): Check that the ink of the static print image absorbent under white light is transparent

under IR light and a dynamically printed characteristic becomes visible in the same position under IR light.

The Contracting Authority SHALL have freedom of choice which security elements in which combinations will be checked.

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 79. Classification and logging of manufacturer- and model-specific check routines according to the

schema given in table 6

4.3.3 CATALOGUE FOR SPECTRALLY SELECTIVE CHECKS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 80. Supporting a catalogue according to [TR-03135-1] p. 5.5. 1.3

32

REQ 81.

Presence of the following information on each generic check routine of a document

model:

• UUID of the check routine;

• Generic check identifier;

• Proprietary check;

• Textual description of the check routine performed;

• Attribute containing the upper limit of the range of values;

• Attribute containing the lower limit of the range of values;

• Attribute containing the threshold configured for the decision for the spectrally selective

verification;

• The bounding rectangle for the checking area; or

• The description of an alternative geometric check region if a bounding rectangle is not

applicable;

• The image section of the reference image region checked against the corresponding database.

REQ 82. Any proprietary decision function for composite generic check routines MUST be described by the

manufacturer and disclosed to the Contracting Authority.

REQ 83. Listing of all test configurations with group checks and decision functions for the given document

models

4.4 DOCUMENT MODEL IDENTIFICATION

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 84. Automatic recognition of a document type and mapping to the document model for all further

modelspecific checking steps.

REQ 85. Document model identification MUST be based on the MRZ7.

7 In case of insufficiency of MRZ analysis refer to REQ. 17

33

REQ 86. The system MUST accept manual input of correct MRZ data from Secunet BioMiddle module to

continue document verification in case of reading and OCR errors.

REQ 87. Parametrization of the UV recording conditions MUST also be performed based on a model

identification.

REQ 88. Identification of the document model based on model mark on the document MUST be supported.

4.5 DOCUMENT AUTHENTICITY VERIFICATION

4.5.1 CHECKING THE MRZ CONSISTENCY

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 89. Verification of control sums in MRZ

REQ 90. Verification of accuracy of MRZ filling-in

4.5.2 SPECTRALLY SELECTIVE VERIFCATION

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 91. Compliance to the verification scenario provided in [BSI-TR-03135-1-v2-1] chapter 5.5.4.2 MUST be

followed.

4.5.3 CROSS VERIFICATION OF DATA

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 92. Cross-verification of data retrieved from MRZ, VIZ (data page area), barcode, RFID-chip SHALL be

part of the document verification scenario.

34

4.6 ELECTRONIC CHECKS OF ELECTRONIC MRTDS

4.6.1 SUPPORT OF THE FOLLOWING PROTOCOLS AND SECURITY MECHANISMS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 93. Basic Access Control (BAC) according to [ICAO9303]

REQ 94. Password Authentication Connection Establishment (PACE) according to [ICAO9303]

REQ 95. Passive Authentication (PA) according to [ICAO9303]

REQ 96. Active Authentication (AA) according to [ICAO9303]

REQ 97. Chip Authentication Version 1 (CA1) according to [TR-03110]

REQ 98. Chip Authentication Version 2 (CA2) according to [TR-03110]

REQ 99. Terminal Authentication Version 1 (TA1) according to [TR-03110]

REQ 100. Terminal Authentication Version 2 (TA2) according to [TR-03110]

35

4.6.2 FILES AND DATA GROUPS TO BE READ

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 101. EF.SOD

REQ 102. DG14

REQ 103. DG15

REQ 104. EF.CVCA

REQ 105. EF.CardAccess according to [ICAO9303]

REQ 106. EF.CardSecurity according to [ICAO9303]

REQ 107. EF.ChipSecurity according to [ICAO9303]

REQ 108. DG1

REQ 109. DG2

REQ 110. DG3

REQ 111. DG11

REQ 112. DG12

4.6.3 PROCESSING SEQUENCES

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 113. Implementation and support for the process sequence described in TR-03135-1 p.5.6.2.1.

REQ 114. Implementation and support for the process sequence described in TR-03135-1 p.5.6.2.2.

REQ 115. Implementation and support for the process sequence described in TR-03135-1 p.5.6.2.3.

REQ 116. Implementation and support for the process sequence described in TR-03135-1 p.5.6.2.4.

4.6.4 CHIP ACCESS VIA BAC OR PACE

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 117. It MUST be possible to configure the system in order that PACE will be used as the primary protocol

and BAC will be used as fallback one.

4.6.5 CHECKING THE CHIP AUTHENTICITY (AA, CA)

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 118. Using CA if both protocols (CA and AA) are supported.

4.6.6 VERIFICATION OF THE SECURITY OBJECTS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 119. Verification of the hash and signature for EF.SOD and mapping to its own final check result

REQ 120. Verification of the hash and signature for EF.CardSecurity and mapping to its own final check result (if

existing)

REQ 121. Verification of the hash and signature for EF.ChipSecurity and mapping to its own final check result (if

existing)

37

REQ 122. Ability to process security objects with one, several or no CDS.

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 123. Verification of the digital signature of a security object.

REQ 124. Comparison of the stored and calculated on site security object's hash values MUST be supported.

4.6.7 CHECKING ISSUER CERTIFICATES

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 125. Check of the issuer certificate for EF.SOD MUST be supported.

REQ 126. Check of the issuer certificate for EF.CardSecurity MUST be supported.

REQ 127. Check of the issuer certificate for EF.ChipSecurity MUST be supported.

REQ 128. Possibility to check CDS signature against its respective CCSCA MUST be supported.

REQ 129. Check if the time at which the check is performed is within the validity period of the CDS MUST be

supported.

REQ 130. Check of the revocation state of the CDS MUST be supported.

4.6.8 INTEGRITY OF CHIP CONTENTS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 131. If the document includes the two files - EF.SOD and EF.COM, mandatory check must be executed to

verify if each data group listed in EF.SOD is included also in EF.COM

38

4.6.9 INTEGRITY OF DOCUMENT CONTENTS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 132.

Comparison of the expiration date of the document and the current date the check was performed

provided by the IS MUST be supported. The expiration date of the document MUST be derived from

MRZ.

REQ 133. Comparison of VIZ data elements against DG1 MUST be supported.

REQ 134. Comparison of the MRZ of the back for consistency against the VIZ of the front MUST be supported.

5 REQUIREMENTS DEFINITION AND TENDER EVALUATION

5.1 REQUIREMENTS DEFINITION

As stated here above in this document all the provided requirements are mandatory.

5.1.1 MINIMUM REQUIREMENTS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

REQ 1 [Requirement title]

[Customer’s Requirement Description]

[Vendor to include, or refer to, supporting documentation that prove/support fulfilment of the minimum

requirement]

Yes/No

REQ 2 [Requirement title]

[Customer’s Requirement

Description]

Yes/No

39

The requirements will be stated as in the example above.

The first column labelled “No.” provides a unique number for each requirement, using the prefix “REQ”. Requirements are numbered sequentially

throughout the document.

The second column labelled “Requirement Description” contains a Requirement Title (bold text) and the Contracting Authority’s Requirement Description.

The requirements are not scored, but evaluated as fulfilled/not fulfilled based on the documentation provided by the Vendor. The Contracting Authority

reserves the right to decide if the Vendor fulfils the requirements or not based on the documentation provided.

The third column labelled “Vendor’s Response” shall be filled by the Vendor to include, or refer to, supporting documentation to convince the Customer

that the requirement is fulfilled. The referenced documentation should be as short and precise as possible.

In the last column labelled “Fulfilled” the Vendor must clearly state whether the Vendor fulfils the requirement (Yes) or not (No). Should the column

“Fulfilled” not be filled in, then the Customer will assume the column to be filled in with “No” and therefore it will constitute a confirmation that the Vendor

cannot comply with the requirements.