readid_flutter

Description:

readid flutter

ReadID Flutter Plugin #
The ReadID Flutter Plugin wraps ReadID's native iOS (Swift) and Android (Kotlin) UI SDKs behind a
Dart interface for use from within your Flutter app.
This plugin wraps the client-server and client-only versions of the native SDKs.
Please contact your technical contact in Inverid or our support for bug reports or feature requests.
Please be aware that a license for ReadID and access to the native SDKs is needed to be able to use
this Flutter Plugin.

ReadID Flutter Plugin

Requirements
Limitations and Known Issues
Repository Contents
Installation

Android

Add ReadID SDK and Configure Build


iOS


Client-server vs client-only
Getting Started
Sample code
Android's Process Termination
Handling errors


Features

Flows

UI/UX
Document selection screen
Instruction animations screens
Manual input screen
VIZ confirmation screen
VIZ result screen
NFC reading screen
NFC result screen
NFC data result section
NFC security result section
Configuration
Configuration options available for all flows
Configuration options available for all VIZ flows
Configuration options available for all NFC flows
VIZOnlyOnePageFlow configurations
VIZOnlyBothSidesFlow configurations
NFCOnlyFlow configuration options
NFCWithAccessControlFlow and NFCWithVIZFallbackFlow configuration options
NFCWithVIZFlow and NFCWithVIZBothSidesFlow configurations
NFC chip support
Document and device NFC location
iProov
Optical Orchestration

Overview
Technical implementation details






Advanced

Custom CSCA Master List (client-only)

Embedded, static custom master list (iOS)
Embedded, static custom master list (Android)
Dynamic custom master list




ReadID Flutter Plugin Data Model Documentation

Flow Objects

Not available at this current time for NFC/VIZ
(Abstract) Flow

Properties


VIZOnlyOnePageFlow

Properties


NFCWithAccessControlFlow

Properties


NFCOnlyFlow

Properties




Result Objects

ReadIDResult

Properties


(Abstract) BaseResult
NFCResult extends BaseResult

Properties


ReadIDSession




License
Help and support

Requirements #

Dart SDK version 3.1 and above.
Flutter SDK version 2.5.0 and above.
iOS 13 and above.
Android API Level 24 (Android 7) and above.
A valid ReadID Access Key and URL.

Refer to the native Android and iOS tech guides on the Documentation portal for platform specific requirements.
Limitations and Known Issues #
A subset of the native SDK API is not available in the Flutter wrapper due to technical limitations. Most notably, this includes:

All Flow configuration properties have a setter but no getter, i.e. you can configure all settings but you cannot query configuration settings.
vizConfirmationScreenConfiguration, vizResultScreenConfiguration, and isTouchToFocusEnabled (Android only) are not available
In the client-only version of the SDK, you can only configure a custom masterlist statically, not dynamically. See Custom CSCA Master List (client-only) for more information.

Refer to the native Android and iOS tech guides on the Documentation portal for platform specific limitations and known issues.
Repository Contents #

README.md - This document.
example - A demonstration Flutter app using this Flutter plugin.
lib - Flutter (Dart) side of the SDK plugin.
android - Android native side of the plugin.
ios - iOS native side of the plugin.

Installation #
You can install this package by running the following command in your Flutter
project: flutter pub add readid_flutter
Android #
We recommend using the latest Android Studio.
Add ReadID SDK and Configure Build

Add repositories to your build.gradle (root scope):

allprojects {
repositories {
google()
maven {
url "s3://maven-readid-7npn738r9muhb5r6mm97b7pxcck84euw1a-s3alias"
authentication { awsIm(AwsImAuthentication) }
}
}
}
copied to clipboard

Configure AWS credentials. Create ~/.aws/credentials with contents:

[default]
aws_access_key_id=<your_key_id>
aws_secret_access_key=<your_access_key>
copied to clipboard
Do not add a newline after aws_secret_access_key.
The aws_access_key_id and aws_secret_access_key are provided to you by Inverid.

Set Java compatibility to Java 8 in your build.gradle (Module: app):

android {
compileOptions {
// Sets Java compatibility to Java 8
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}
copied to clipboard

Add AndroidX properties to your gradle.properties (project root). Create if it
does not exist:

android.useAndroidX=true
copied to clipboard

Add required features for NFC: Add the nfc feature to your AndroidManifest.
xml.

<uses-feature
android:name="android.hardware.nfc"
android:required="true"/>
copied to clipboard

Optional: add required features for VIZ: Add camera and autofocus features to
your AndroidManifest.xml. As an alternative, you can perform runtime checks
before starting ReadID, in case you want to support devices without camera or
without auto focus.

<manifest>
...
<uses-feature
android:name="android.hardware.camera"
android:required="true"/>
<uses-feature
android:name="android.hardware.camera.autofocus"
android:required="true"/>
</manifest>
copied to clipboard
If you start any NFC flow and the device does not have NFC support, then the plugin will throw
an NFCNotSupportedException. You should perform runtime checks before starting ReadID and handle
the NFCNotSupportedException. The exception here is that if you make use of
the NFCWithVIZFallbackFlow, then the plugin will perform the check, and will fall back to a second
VIZ capture if the device does not support NFC.
Finally, do not forget to set the Android minSdkVersion to at least 24
iOS #
We recommend using the latest version of Xcode.
The ReadID-UI SDK consists of 2 Swift frameworks: ReadID.xcframework and ReadID_UI.xcframework. Both
include simulator builds that provide mockups for features that are not available on the simulator,
especially those that involve the camera or NFC reader. When using ReadID UI VIZ, using the
simulator requires you to configure a movie to simulate camera input. See Simulating VIZ capture in
the iOS Simulator for more information.
You can use the sample code to get started quickly or you can integrate the ReadID UI SDK into your
own app as follows:

On the General configuration tab of your App Target configuration, add ReadID.
xcframework and ReadID_UI.xcframework to 'Frameworks, Libraries, and
Embedded Content'.
On the Signing & Capabilities configuration tab add the
Capability Near Field Communication Tag Reading
Add NSCameraUsageDescription to the App's Info.plist file. The camera is
needed to scan the document, including the MRZ.
Add NFCReaderUsageDescription to the App's Info.plist.
On the Apple developer portal create a distribution provisioning profile and enable
capability NFC Tag Reading.
Copy the snippet below into your Info.plist. This is the list of application identifiers that are
supported, see Core NFC documentation for more information.

<key>com.apple.developer.nfc.readersession.iso7816.select-
identifiers</key>
<array>
<string>A0000002471001</string>
<string>A00000045645444C2D3031</string>
</array>
copied to clipboard
In order to start the ReadID flow, you must include the native ReadID frameworks (.xcframework) in
your Flutter ios folder.
Please consult your onboarding specialist so you can get access
to ReadID_Interop.xcframework, ReadID_UI.xcframework and ReadID.xcframework.
Once you have obtained these frameworks, be sure to add them to your iOS project. You can do so by
opening your project in Xcode, select the main target, go to General -> Frameworks, Libraries and
Embedded Content and drag them there. Please make sure that the Embed & Sign option is selected
for all of them.
Afterwards, you will need to edit the Podfile of your Pods project. Make sure the post_install
code block looks like this:
post_install do |installer|
installer.pods_project.targets.each do |target|
if target.name == 'readid_flutter'
xcframeworks_paths = ['../ReadID_Interop.xcframework', '../ReadID.xcframework', '../ReadID_UI.xcframework']
xcframeworks_group = installer.pods_project.main_group.find_subpath('Frameworks', true)
xcframeworks_paths.each do |path|
file_ref = xcframeworks_group.new_file(path)
target.frameworks_build_phase.add_file_reference(file_ref, true)
end
end
end
installer.pods_project.targets.each do |target|
flutter_additional_ios_build_settings(target)
end
end
copied to clipboard
Make sure you include the NFCReaderUsageDescription and NSCameraUsageDescription keys in
your Info.plist with descriptions about why you want to use the NFC and Camera capabilities.
For example:
<key>NFCReaderUsageDescription</key>
<string>Read an electronic passport or drivers license</string>
<key>NSCameraUsageDescription</key>
<string>We need access to the camera to capture the document before reading the NFC chip</string>
copied to clipboard
To access a particular function of the NFC chip, it is required to select the corresponding
applications first. Apple
requires you to specify these explicitly in your Info.plist.
Declare com.apple.developer.nfc.readersession.iso7816.select-identifiers as follows:
<key>com.apple.developer.nfc.readersession.iso7816.select-identifiers</key>
<array>
<string>A0000002471001</string>
<string>A00000045645444C2D3031</string>
</array>
copied to clipboard
Lastly, also enable the NFC Tag Reading capability in your target. You can do so by:

Open your iOS Flutter project in Xcode.
Click on your app target.
Go to Signing & Capabilities tab.
Click the + Capability button.
Add the Near Field Communication Tag Reading.

Client-server vs client-only #
In most situations, the ReadID client-server SDK is the most suitable solution. If you need to use
the client-only solution this can be accomplished in iOS simply by adding the correct version of the
xcframework. For Android, in your app's build gradle you need to add the following line:
gradle.ext.readIDFlavor = 'clientOnly'
copied to clipboard
Getting Started #
To use the SDK, you must obtain credentials first. You can obtain your AccessKey and URL by
contacting your onboarding specialist.
Once you have a valid token (obtained via Credentials), you can start to setup a flow (for example
an NFCWithAccessControlFlow or VIZOnlyOnePageFlow). With your newly created flow, you can start
using the ReadID plugin.
The most simplest form is the following:
final myFlow = NFCWithAccessControlFlow()
..baseUrl = 'Your URL'
..accessKey = 'Your access key'
..allowedDocumentTypes = [DocumentType.passport,
DocumentType.identityCardTD1];
final readIDResult = await ReadID().startReadID(flow: myFlow);
copied to clipboard
This will start the ReadID plugin and will allow your users to verify themselves using a passport or
an identity card.
The readIDResult will contain information about the session the user just performed. Depending on
the flow that was selected, it's possible to retrieve the users name, photo image, and more.
For instance, if the user scanned their identity document using NFC, you can retrieve their face
image in the following way:
final faceImage = readIDResult.nfcResult?.faceImage;
copied to clipboard
The faceImage is a regular UInt8List, which you can display using the Image class in Flutter,
for example.
Sample code #
For a simple ReadID experience that is ready to run out-of-the-box, check out the Flutter example
project. Note that ReadID is not supported on an iOS or Android simulator, you have to run it on a
physical device.
In the example app folder, open the main.dart file. Here you will see instructions on how to setup
your base URL and access key.
// Put your API credentials in a json file and pass them using --dart-define-from-file
final String _baseUrl = const String.fromEnvironment('BASE_URL');
// Note: You should have different access keys for each server environment
final String _accessKey = const String.fromEnvironment('ACCESS_KEY');
copied to clipboard
NOTE: Never commit or store your AccessKey or URL in publicly accessible code. Always use secure
methods to store and retrieve these credentials in production environments.
Android's Process Termination #
Android may kill an app's process to reclaim memory, prioritizing the termination of background apps
or those not performing active tasks, with minimal impact managed through proper app lifecycle
handling. To handle this we have a method that can be called in Flutter
resumeReadID();
copied to clipboard
The resumeReadID() function is designed to resume passing the readIDResults to the Flutter app.
It checks for previous results from onActivityResult() and will pass along the last one, if we
have one, back to the app.
You can see in ~/example inside the main.dart on how you could call this from the initState()
Handling errors #
The startReadID function can throw an error, for example the user didn't scan their identity
document correctly. These errors are Failure objects. A list of errors that you can encounter are
listed below:



Exception
Description




backgroundTimeout
App was in the background longer than the configured interval.


sessionExpired
The session with the server has expired.


authorisationError
Indicates that you have configured a wrong or invalid server access key or oAuth token.


serverSessionError
Happens if the server is either unavailable or encountered an error while processing a request.


sslError
This can happen if SSL pinning is enabled and the SDK was not able to accomplish a secure connection to the server. The cause could be an expired or incorrect certificate.


nfcAccessControlError
Indicates incorrect NFC chip credentials (e.g. BAC access key) due to an OCR error or incorrect user input. It also happens if the user changed the identity document between VIZ capture and NFC reading, which means the credentials are meant for a different chip and are therefore wrong.


connectionError
Indicates that a network error occurred while attempting to communicate with the server. A message with "Try again" and "Cancel" option was shown, but the user was not able to succeed and cancelled.


nfcError
Happened most likely because of a weak NFC connection with the chip. The user was not able to read the chip, and the OS NFC reading timeout has occurred.


userCancelled
User cancelled the reading process by the following methods: User pressed skip on the NFC read screen or the user closed using modal screen.


cameraPermissionDenied
The user did not give permission to use the camera.


noChip
According to our records, the document does not have a chip.


unsupportedDocument
The document is not supported by ReadID.


wrongDocumentType
This failure is thrown when an ICAO document (passport or identity card) MRZ is scanned and an EDL document (driving licence) is used to be read or vice versa.


tooManyRequestsError
Happens if the server reached the maximum allowed requests in a certain time for the configured account.


expiredSDK
The ReadID SDK used is no longer supported.


backNavigation
The user closed the identity verification process by hitting the back button.



Features #
Flows #
The UI SDK supports several different "Flows" that determine how and what you want to capture or
read from the document. The following flows exist:


VIZOnlyOnePageFlow: Captures a single configured page type. You can "chain" this flow with
another VIZOnlyOnePageFlow and/or NFCOnlyFlow in order to achieve the most flexibility w.r.t.
UX/UI, such as presenting your own instructions, animations, and/or feedback screens.


VIZOnlyBothSidesFlow: Captures both sides of a configured document type.


NFCWithAccessControlFlow: This flow is optimized for reading the document's NFC chip. It will
attempt scan the document's MRZ page for access control information, and will also provide the
option to enter the access control key manually. Once it has obtained the access control key it
will proceed to read the document. This flow may or may not return a usable VIZ capture of the
document. Note that if you require the personal number when using this flow, it can result in
lower VIZ capture performance, because the flow may have to capture a QR code too. See Flow.
shouldRequirePersonalNumber below.


NFCOnlyFlow: Only read the identity document's NFC chip. This flow can be combined with the
VIZOnlyOnePageFlow in order to implement custom business logic in between and around these flows.
It is typically used when none of the other flows sufficiently matches your use case. It can also
be used without the ReadID UI VIZ SDK entirely.


NFCWithVIZFlow: Scan the document's MRZ page, then read the chip. Use this flow when you want to
acquire a high quality VIZ image and/or features and read the document's NFC chip.


NFCWithVIZBothSidesFlow: Scan both sides of a document, including the MRZ page, then read the
chip. Use this flow when you want to acquire high quality VIZ images of both sides of a document
as well as read the document's NFC chip.


NFCWithVIZFallbackFlow: Scan the access control information, then tries to read the chip. If the
chip cannot be read, then this flow will instead scan the other side of the document. That
fallback (scanning the other side) happens if the device does notes to skip reading, after the SDK
detects an unsupported / no chip, or after an NFC read failure.Fallback does not happen if you
have disabled the Skip button or if the user declines to enable NFC. Use this flow when NFC
reading is your first priority, but fallback to an optical solution is needed if Confidentiality:
Restricted NFC reading fails.



The VIZ SDK will attempt to scan only the requested page or document type(s), as specified
via VIZOnlyOnePageFlow.allowedPageTypes or .allowedDocumentTypes for the other flows, but we
cannot guarantee that the result is of the requested type. The more distinctive features a page has,
the higher the chance that the SDK captures the correct page type, and vice versa, but there is
always the possibility of a wrong page type. If you rely on the VIZ capture result to be accurate
then you must verify the page capture results via some other means. We recommend to always use NFC
reading, if possible, and rely on those results instead.

UI/UX #
The Flow that you choose to use also defines the screens that the SDK should present to the user,
their order, and the possible transitions between those screens. The following screens exist:

Document selection screen
Instruction animation screen
VIZ capture screen
Manual input screen
VIZ confirmation screen
VIZ result screen
NFC instruction animation screen
NFC reading screen
NFC result screen

All screens except the VIZ capture screen and NFC reading screen are optional:


The document selection screen can be shown or disabled by using Flow.
shouldShowDocumentSelection and is described in section Document selection
screen below.


The instruction animation screen can be disabled by setting Flow.instructionsPlayCount to 0. We recommend leaving the animations enabled
unless your app targets expert users.


The option to enter NFC access control data manually on the manual input
screen is only available in NFCWithAccessControlFlow. That flow is intended to
capture an NFC access control key, and is optimized towards that goal at the expense of the
quality of the VIZ image and features.


To disable the VIZ result screen, set Flow.shouldShowVIZResult to false.


The NFC instruction animation screen can be disabled with Flow.instructionsPlayCount = 0. We recommend leaving the animations enabled
unless your app targets expert users.


The manual access key input screen will only be shown during the
NFCWithAccessControlFlow, if the SDK detects a wrong NFC access key
(extracted from the MRZ).


You can skip the NFC result screen with Flow.shouldShowNFCResult = false. It is shown by default.


You can show the NFC security result section by setting Flow.nfcResultScreenConfiguration.shouldShowSecurityResult = true. It is
skipped by default.


Document selection screen #
ReadID UI VIZ can show a document selection screen that allows users to choose the type of document
to scan. Depending on the choice, ReadID UI VIZ can display specific Instruction animations and a
VIZ capture-screen screen tailored to that document type.
This screen is disabled by default. Enable it by
setting Flow.shouldShowDocumentSelection to true.
You can configure the document types that the user can choose for the VIZOnlyOnePageFlow
with VIZOnlyOnePageFlow.allowedPageTypes. For other flows with Flow.allowedDocumentTypes.
The following buttons can be shown (with their MRZ format)

Passport for ICAO compliant passports (2x44 characters)
Identity card for ICAO TD1 (3x30 characters) and ICAO TD2 (2x36 characters)
compliant identity cards
Driving licence for EU driving licences (1x30 characters) and non-EU compliant
driving licences without MRZ
Visa for ICAO compliant visas (2x36 and 2x44 characters)
French identity card for ICAO TD1 compliant identity cards (3x30 characters)
and CNIS (French identity cards; 2x36 characters)

Instruction animations screens #
ReadID UI provides dynamically generated animations to help the user scan the VIZ of an identity
document or read the document's chip. The animations explain how to properly position and align the
user's document with their mobile device. Animations are generated based on our knowledge of what a
document looks like and where the chip is located. For visas, the SDK displays a static image
instead of an animation.
By default the instruction animations will be played indefinitely. Static graphics will always
remain on screen until the user presses the "Next" button.
You can disable instruction animations with Flow.instructionsPlayCount = 0. We recommend leaving
the animations enabled unless your app targets expert users who know how to successfully scan a
document.
The number of (re)plays can be changed with Flow.instructionsPlayCount. Setting this to -1
configures the SDK to replay the instruction animations indefinitely, until the user presses the "
Next" button. Setting it to a positive value n plays the animation n times before automatically
navigating to the next screen.
The SDK keeps track of which document types have been scanned successfully before on this device.
Once a user has successfully scanned a certain document type, then by default the SDK will no longer
show instructions for that specific document type. This behavior can be changed by
setting Flow.shouldOnlyShowInstructionsOnFirstUse to false.
Manual input screen #
The manual input screen provides a fallback for users for when VIZ capture is unable to scan the
MRZ. It allows users to manually input the fields necessary to compute the access key. This screen
is only available in NFCWithAccessControlFlow, for ICAO compliant identity documents and for
electronic driving licences.
VIZ confirmation screen #
The VIZ confirmation screen is shown immediately after the capture of a single page of a document.
It provides the user with the option to review the capture, and to repeat the scan of the same
page (discarding the result), or to keep the scan and proceed to the next step.
This option can be enable or disabled using Flow.shouldShowVIZConfirmation.
The VIZ confirmation screen can show a set of images, which can be configured with
the VIZConfirmationScreenConfiguration properties. The VIZConfirmationScreenConfiguration can be
retrieved and modified with Flow.vizConfirmationScreenConfiguration.
Note that the VIZ confirmation screen is never shown when manual input was provided.
VIZ result screen #
The VIZ result screen shows the result of the VIZ capture process. You can configure this screen to
show various pieces of information. To do so, first specify which types of information should be
displayed by setting Flow.vizResultDataMode to:


VIZResultDataMode.none: Do not show document content data.


VIZResultDataMode.accessControl: Show only access
control information.


VIZResultDataMode.advancePassengerInformation: Show information that is relevant for airlines
and
border control.


VIZResultDataMode.all: Show all available information.


Next to the textual information, you can choose to display the following images from the document:


Full MRZ image: a crop of the VIZ image that shows only the MRZ.


MRZ field crops: a crop of each displayed MRZ field. This is useful in cases where the
user should validate the MRZ results.


Full VIZ images: the full captured image of the document.


QR code image: a crop of the VIZ image that shows only the QR code.


All images are disabled by default and can be configured with the properties
in Flow.vizResultScreenConfiguration.
In cases where it is desired to not show personal data on a result screen (for example for demo
purposes), it is possible to mask personal data with Flow.shouldMaskPersonalData to true. This
will cause the SDK to replace personal data with * characters and to hide images that contain
personal data. Personal data includes:


The document number


Optional data (can contain the personal number)


Note that the VIZ result screen is never shown when manual input was provided.
NFC reading screen #
The NFC reading screen displays the progress of the NFC reading process. Prior to and during the
reading process, it shows an instruction carousel with useful tips for the document type to be read.
If the user navigates to this screen, first the instruction carousel is shown. As soon as the user
clicks the 'Start reading' button (iOS) or the phone detects a supported NFC chip (Android), the
screen shows the reading progress. If the reading process fails because of a wrong access key, the
SDK will let the user verify the used access information by showing the manual input screen, or it
will restart the reading process automatically. For the ReadID UI VIZ variant, the manual input
screen is only available in the NFCWithAccessControlFlow flow. If the reading process fails
because of another problem, typically a lost connection, this screen displays an error and lets the
user try again.
If NFC reading finishes with an access control error and manual input is disabled/not supported,
then the SDK returns to the VIZ or MRZ capture screen. If you are not using the ReadID UI VIZ SDK at
all, the SDK returns control with an NFC access control error.
NFC result screen #
The ReadID UI NFC result screen shows chip data and validation results. It is shown by default can
be disabled by setting Flow.shouldShowNFCResult = false.
NFC data result section #
The NFC data result section of the NFC result screen can be configured to show various elements by
setting Flow.nfcResultScreenConfiguration.nfcResultDataMode to:

none: do not show information from the document content.
simple: show a subset of information read from the chip, if available:

Given names
Last name
Gender (only ICAO compliant documents)
Nationality (only ICAO compliant documents)
Date of birth
Place of birth (only driving licences)
Personal number (not always available)
Document code (only ICAO compliant documents)
Document number
Issuing country
Date of expiry
Driving licence categories (only driving licences)


all: show all information that was read from the chip.

Note: Certain information, such as fingerprints, cannot be shown simply because it cannot be read
without a government-issued private key. Only a select group of government related organisations
have access to this information.
In addition to the textual information, the result screen can show:

Verification result (configurable with shouldShowVerificationResult)
Face image (configurable with shouldShowFaceImage)
Signature image (configurable with shouldShowSignatureImage, not always
available)

The shown information can be configured via NFCResultScreenConfiguration which can be accessed and
modified with Flow.nfcResultScreenConfiguration.
When you do not want to show personal data other than the face image on the result screen, for
example for demo purposes, you can mask that data by setting Flow.shouldMaskPersonalData = true.
As a result, the SDK will replace personal data with * characters. Fields that are masked are:

Document number
Personal number
Machine Readable Zone (MRZ)

NFC security result section #
The security information section of the NFC result screen shows security-related chip information,
including:

Data version
Chip features
Data groups read
Access control type and results
Active Authentication (AA) and Chip Authentication (EAC-CA) results
Passive authentication results
Document- and Country-signing certificates
Individual data group hashes and comparison results

The security result section in the NFC result screen can be enabled by
setting Flow.nfcResultScreenConfiguration.shouldShowSecurityResult = true.
Configuration #
This section gives an overview of the configuration options when using the ReadID UI NFC SDK for use
with ReadID UI VIZ, for each of the supported flows. For more details and default values read the
apidocs delivered with the ReadID UI SDK package.
Be aware that not all identity documents are the same and that ReadID UI NFC will attempt to choose
the best configuration regarding access control (BAC or PACE), speed of NFC reading, and user
guidance (e.g. how to align the user's device with the document) based on information that is passed
from ReadID UI VIZ.
If you do not use ReadID UI VIZ (NFCOnlyFlow only), you'll need to provide an instance
of NFCAccessKey, as it is required for access control. You should also provide a DocumentInfo
object, to give ReadID UI NFC enough information to choose the best NFC configuration.

The SDK will attempt to scan only the requested document type(s), as specified
via Flow.allowedDocumentTypes, but we cannot guarantee that the result is of the requested type.
The more distinctive features a page has, the higher the chance that the SDK captures the correct
page type, and vice versa, but there is always the possibility of a wrong page type. If you rely on
the VIZ capture result to be accurate then you must verify the page capture results via some other
means.

If you attempt to capture both drivingLicence and euDrivingLicence (or the front of said
documents), then VIZ capture will always attempt to scan a EU driving licence containing an MRZ
first, to maximize the chances of detecting a document that contains a chip. This may reduce capture
speed when the user attempts to scan a driving license without an MRZ.
Configuration options available for all flows #

Flow.baseURL: Sets the base URL of the target ReadID server or reverse proxy. If you change the
base URL, you must override the pinning certificates with the (CA) certificate of the used server.
Flow.accessKey: Sets the ReadID access key for server authentication.
Flow.oauthToken: Sets the OAuth token for server authentication.
Flow.opaqueID: This customer-provided identifier can be used to cross-reference a ReadIDSession
to an app session identifier.
Flow.shouldUsePinning: Enables/disables SSL pinning. Should only be set to
false for debug purposes.
Flow.readIDSession: Sets a ReadIDSession. The ReadIDSession is optional and only needs to be set
if a previous session should be reused. Note: A ReadIDSession can only be committed once to the
server. To prevent a session commit use the following configuration.
Flow.preventSessionCommit: Sets whether a session commit should be
prevented. This is useful if you want to reuse a ReadIDSession, for example if you want to capture
both VIZ images, but also interact with your app between.
Flow.instructionsPlayCount: Sets the instruction play count. 0 disables
instructions and <0 replays the instruction until the user pressed next.
Flow.shouldOnlyShowInstructionsOnFirstUse: Enables/disables only show
instructions on first use. By default it is set to true and instructions will only be shown until
the user accomplished the related action.
Flow.shouldMaskPersonalData: Enables/disables replacing personal data
(document number and optional data) with * characters.
Flow.shouldAllowScreenshots (Android only): If allow screenshots is enabled, it is possible to
make screenshots and screen recordings on the screens of the library, and it is possible to see
content in the OS recent apps list.
Flow.dateFormat: Sets the date format in the manual input screen.
Flow.dateSeparator: Sets the date separator in the manual input screen.
Flow.backgroundTimeout: Sets after how many milliseconds (Android) or seconds (iOS) in the
background the library returns to the hosting application.
Flow.readIDTracker: A ReadIDTracker can be implemented and set to be able to
log events inside ReadID UI. Note: This is not stored as a weak reference. So be carefully with
implementing the ReadIDTracker to prevent memory leaks.
Flow.language: Sets the language to the given language value. Default or if null is applied, the
device language will be used, if supported. Fallback is English.

Configuration options available for all VIZ flows #

Flow.shouldShowVIZConfirmation: Sets whether a VIZ confirmation screen
should be shown, where the user can check and confirm the VIZ image quality.
Flow.vizResultMode: Defines which fields are shown on the VIZ result screen.
Flow.shouldShowVIZResult: Defines if to show VIZ result screen.
Flow.shouldShowVIZPerformanceResult: Sets whether the VIZ performance result should be shown. If
enabled a "Performance" tab is shown on the VIZ result screen. This is useful for debug purposes.
Flow.shouldShowMRZFieldImages: Sets show MRZ field images enabled/disabled.
Flow.shouldShowMRZText: Sets show MRZ text enabled/disabled.
Flow.shouldShowMRZImage: Sets show MRZ image enabled/disabled.
Flow.shouldShowVIZImages: Sets show VIZ images enabled/disabled.

Configuration options available for all NFC flows #

Flow.shouldShowInstructionCarousel: Sets whether the instruction carousel
should be shown.
Flow.nfcResultMode: Sets the NFC result mode. Note: use Flow.
shouldShowNFCResult to enable or disable the result screen entirely.
Flow.shouldShowNFCResult: Disables NFC result screen. Must be set to false if
NFCResultMode.none.
Flow.shouldReadImages: Sets whether images should be read from the NFC chip.
Flow.shouldShowFaceImage: Sets whether the face image should be shown.
Flow.shouldShowVerificationResult: Sets whether the verification result
should be shown.
Flow.shouldShowSecurityResult: Sets whether the security result should be
shown.
Flow.allowResumeNFCReading: Attempt to resume NFC reading where it left off
after a disconnect. Enabled by default.
Flow.allowSkipReadingAfterAttempts: Shows a skip-button on the NFC
reading screen after a specified number of attempts.
Flow.accessControlOption: Sets the desired access control option to access the document chip.
Flow.extendedLengthAPDUPreference: Sets the desire extended length APDU
preference. This is a beta feature. Do not use in production.
Flow.cscaMasterLists: Not available in Flutter.
Flow.applicationLevelEncryptionPins: Array of certificate pins for application-level encryption.
Pins can be obtained via the ReadID management portal. Each pin must be specified as a
base64-encoded sha256 hash of the SubjectPublicKeyInfo. By default, certificate pinning for
application-level encryption is disabled.

VIZOnlyOnePageFlow configurations #

VIZOnlyOnePageFlow.allowedPageTypes: Sets the allowed page types. We
recommend to allow only one page type, because allowing multiple page types will reduce the
performance.
VIZOnlyOnePageFlow.mrzValidation: Sets the MRZ validation. If only access
control information for accessing the chip is needed, we recommend to use
MRZValidation.accessControl. If also other fields in the
MRZ should be correct, use MRZValidation.full, but it could make the
capture process slower.
VIZOnlyOnePageFlow.fastCaptureMode: Enables or disables fast capture mode.
If enabled, VIZ capture will focus (only) on scanning the MRZ as fast and accurate as possible. If
disabled, VIZ capture will focus on producing a high quality image capture. Note that fast capture
mode can only be enabled if
faceImageFeatureRequirement and qrCodeFeatureRequirement are both set to notRequired.
VIZOnlyOnePageFlow.manualCaptureAllowedAfterTimeout: Sets after how
many milliseconds a manual capture button should be shown. A negative value will never show the
button.
VIZOnlyOnePageFlow.mrzFeatureRequirement: Sets the MRZ feature
requirement.
VIZOnlyOnePageFlow.faceImageFeatureRequirement: Sets the face image
feature requirement.
VIZOnlyOnePageFlow.shouldRequireSharpImage: Sets whether a sharp image
is required.
VIZOnlyOnePageFlow.shouldRequireNoGlareOnDocument: Sets whether no
glare on document is required.
VIZOnlyOnePageFlow.shouldRequireNoFingerOnDocument: Sets whether no
finger on document is required.
VIZOnlyOnePageFlow.shouldAllowLoweringQualityRequirements: Sets
whether it is allowed to lower the above 3 quality requirements in time.
VIZOnlyOnePageFlow.qrCodeFeatureRequirement: Sets the QR code feature
requirement.


The SDK will attempt to scan only the requested page type(s), as specified
via VIZOnlyOnePageFlow.allowedPageTypes, but we cannot guarantee that the result is of the
requested type. The more distinctive features a page has, the higher the chance that the SDK
captures the correct page type, and vice versa, but there is always the possibility of a wrong page
type. If you rely on the VIZ capture result to be accurate then you must verify the page capture
results via some other means. We recommend to always use NFC reading, if possible, and rely on those
results instead.

VIZOnlyBothSidesFlow configurations #

VIZOnlyBothSidesFlow.allowedDocumentTypes: Sets the allowed document
types. We recommend to allow only one document type, because allowing multiple
document types will reduce the performance.
VIZOnlyBothSidesFlow.shouldShowDocumentSelection: Sets whether the
document selection screen should be shown.
VIZOnlyBothSidesFlow.shouldRequirePersonalNumber: Sets whether to
retrieve the personal number from the MRZ or from a QR code on the document. The latter occurs on
Dutch passports and ID cards from late 2021 or newer. If you enable this option, the SDK will
automatically detect Dutch documents with a BSN in the QR, and will require a scan of that QR.
Note that this process may fail due to, for example, OCR mistakes that prevent the SDK from
detecting that the document is Dutch.


Obtaining the personal number from the scanned MRZ or QR code is unreliable due to the lack of
mechanisms to protect the integrity and authenticity of data, unlike for data read from the chip.


The SDK will attempt to scan only the requested page types, as specified
via VIZOnlyBothSidesFlow.allowedDocumentTypes, but we cannot guarantee that the result is of the
requested type. The more distinctive features a page has, the higher the chance that the SDK
captures the correct page type, and vice versa, but there is always the possibility of a wrong page
type. If you rely on the VIZ capture result to be accurate then you must verify the page capture
results via some other means. We recommend to always use NFC reading, if possible, and rely on those
results instead.

NFCOnlyFlow configuration options #
NFCOnlyFlow supports all common configuration options, plus the following:
NFCOnlyFlow.preventChipSupportDialog: Sets whether chip support warning
dialogs should be prevented. This is useful when the chip support was already
checked by the app before starting the NFC flow and the app allows to try to read the NFC chip
anyway.
When combining the VIZOnlyOnePageFlow with this flow, you typically need to pass the
existing readIDSession to the NFCOnlyFlow so that it can use the already obtained NFC access key
and other information. See the Usage section or the sample code for more information.
NFCWithAccessControlFlow and NFCWithVIZFallbackFlow configuration options #
NFCWithAccessControlFlow and NFCWithVIZFallbackFlow support all common configuration options,
plus the following:

Flow.shouldShowDocumentSelection: Sets whether the document selection
screen should be shown.
Flow.shouldShowVIZConfirmation: Sets show VIZ confirmation screen enabled
/disabled.
Flow.allowedDocumentTypes: Sets the list of allowed document types that can be captured. Note
that if the user doesn't capture their document, but enters the access control manually, then this
list does not apply.
Flow.vizResultMode: Configures what should be shown on the VIZ results screen.
Flow.shouldShowVIZPerformanceResult: Sets whether the VIZ performance
result should should be shown or not.
Flow.shouldShowMRZFieldImages: Sets show MRZ field images enabled/disabled.
Flow.shouldShowMRZText: Sets show MRZ text enabled/disabled.
Flow.shouldShowMRZImage: Sets show MRZ image enabled/disabled.
Flow.shouldShowVIZImages: Sets show VIZ images enabled/disabled.
Flow.shouldShowQRCodeImage: Sets show QR code image enabled/disabled.
Flow.shouldRequirePersonalNumber: Sets whether to retrieve the personal
number from the MRZ or from a QR code on the document. The latter occurs on Dutch passports and ID
cards from late 2021 or newer. If you enable this option, the SDK will automatically detect Dutch
documents with a BSN in the QR, and will require a scan of that QR. Note that this may cause the
SDK to ask the user to scan the back of their passport, after scanning the front but before NFC
reading starts, as that is where the QR code resides. Also note that this process may fail due to,
for example, OCR mistakes that prevent the SDK from detecting that the document is Dutch.


Obtaining the personal number from the scanned MRZ or QR code is unreliable due to the lack of
mechanisms to protect the integrity and authenticity of data, unlike for data read from the chip.


The SDK will attempt to scan only the requested page type(s), as specified
via Flow.allowedDocumentTypes, but we cannot guarantee that the result is of the requested type.
The more distinctive features a page has, the higher the chance that the SDK captures the correct
page type, and vice versa, but there is always the possibility of a wrong page type. If you rely on
the VIZ capture result to be accurate then you must verify the page capture results via some other
means.

NFCWithVIZFlow and NFCWithVIZBothSidesFlow configurations #
NFCWithVIZFlow and NFCWithVIZBothSidesFlow support all options from NFCWithAccessControlFlow
flow, plus the following:

NFCWithVIZFlow.shouldCommitSessionWithoutNFC: Sets whether a session
should also be committed to the server if NFC reading did not succeeded. This can happen if the
user skipped NFC reading or if the SDK detected a document without chip.

NFC chip support #
ReadID UI VIZ produces a VIZResult which contains, among other results, the likelihood of whether
or not the NFC chip of the scanned document is supported. We actively maintain a database that is
used as the basis for this information, in an attempt to make this as accurate as possible. However,
the assessment may be incorrect, and is provided as-is.
The NFC chip support status can be checked with the following code:
Android, where the Activity result is received:
ReadIDUI.getResult(VIZResult::class.java, data)?.let { vizResult ->
val nfcChipSupport = vizResult.nfcChipSupport
}
copied to clipboard
iOS, once you have obtained a vizResult from the ReadIDUI.identify() call:
let nfcChipSupport = vizResult.nfcChipSupport
copied to clipboard
The NFC chip support will always be one of the following values:

supported: The NFC chip of the document is supported by ReadID.
unsupported: The chip of the document is not supported by ReadID.
noNFCChip: The document does not have a NFC chip.
unknown: The NFC chip support is unknown. This can be the case for very old and for very
recently issued documents.

Please be aware that the NFC chip support may be sub-optimal or even wrong. For example, if a state
suddenly starts issuing identity documents with supported chips, where that was not the case
previously. Or a document that normally has a chip may be issued without a chip in a different
location, as temporary document. We actively maintain our knowledge regarding chip support to keep
it as accurate as possible. Therefore, please make sure to update to the latest release as soon as
possible. The old version of the SDK will have outdated information.
Document and device NFC location #
ReadID UI VIZ produces a VIZResult which contains, among other results, the location of the NFC antenna on the document and the device. The latter is only available on Android. For iOS, the device NFC antenna is always in the top middle of the device.
The result can be used to implement custom instruction
animations. We actively maintain a database that is used as the basis for the document and device
NFC location in an attempt to make these locations as accurate as possible. However, the assessment
may be incorrect, and is provided as-is.
You can retrieve the document and the device antenna location using VIZResult.documentNFCLocation and VIZResult.deviceNFCLocation.
Please be aware that the document and device NFC location may be sub-optimal. It can even be outdated or wrong, for
example when a state suddenly starts issuing identity documents with a different NFC chip location, or when a certain device manufacturer brings out a new device with a different NFC reader location than previous models. We strive to keep our location database as up-to-date as possible.
iProov #
Facial verification is an additional service that this plugin can provide if it was contractually
agreed upon. iProov is a facial verification service that verifies that there is a real, live person
doing the identity verification and that their face matches the photo from the NFC chip of their
document. It does this by taking a selfie-video and the face image from the document, and sending
both to iProov for verification.
iProov facial verification takes place after reading the user's identity document, so that the
ReadID Server can enrol the authentic, verified face image from that document to iProov. The face
image is used as a reference image for comparison with the selfie video. Once the iProov service has
completed the assessment, the verification results are added to the ReadID session and can be
retrieved from the ReadID Server.
ReadID is also able to use the face image extracted from the document's Visual Inspection Zone (VIZ)
instead of the chip. This is only intended as a fallback scenario for when the chip cannot be read,
and should be used with caution.
Using a VIZ face image is considered to be much less reliable than using the image read from the
chip, as VIZ images are not subject to the authenticity and clone detection mechanisms that apply to
chip data. We cannot guarantee that we have extracted the correct, original face image. A malicious
user can trick ReadID VIZ because of bad lightning, poor camera quality, etc. If you decide to use
the VIZ face image for iProov, we strongly recommend to do so only in combination with optical
orchestration and to perform manual check of the face image. All VIZ images are available via the
management portal, the REST API, and in the PDF.
To combine iProov facial verification with ReadID, you will need to configure it on the ReadID
server and implement it within your Flutter app.
To configure it on the server:

Enable iProov for the submitter application that you use in your app.
Ensure that you have selected the correct profile, Genuine Presence Assurance or Liveness
Assurance.

To implement orchestration with iProov from within your flutter app, you must add the iProov flutter
plugin to your project. It is available at https://github.com/iProov/flutter, including instructions
to add the iProov plugin. It is required to make a "selfie video" that will be analyzed and compared
with the reference face image.
Then, for each iProov orchestration session, implement the following:

Make sure that the ReadID session has been committed to the server before starting the iProov
process. The session is normally committed automatically by the ReadID SDK, unless you prevent
session commits via your Flow configuration.
Start an iProov attempt by requesting an iProov token using retrieveIProovVerifyToken method.
Launch the iProov SDK to take the user's selfie video:
Finalize the attempt and retrieve iProov verification results using validateIProovVerifyToken
method.
Repeat steps 2-4 until the user passed verification or until there are no more attempts left.

Start an iProov Attempt:
Use the retrieveIProovVerifyToken method to start the iProov process. This is an asynchronous call
that does two things:

Request the ReadID Server to enrol the reference face image (taken from the already committed
session) with iProov.
Return a token that can be used to start the iProov SDK.

The retrieveIProovVerifyToken response, successful or not, is always returned via a callback. The
ReadID SDK will poll the ReadID server for a response, for at most 10 times with a delay of 1 second
between each request.
Start the iProov SDK:
Once you have a valid iProov verifyToken, start the iProov SDK using the IProov.launch() method.
A detailed explanation of how to configure the iProov SDK, use the launch() method, implement the
required callbacks, and obtain and interpret the results which is provided on the Github page of
iProov flutter plugin. The page also contain information on how to handle failures and errors during
this step of the process.
Once the iProov SDK has reached a final state (success, failure, cancelled, or error) you must
continue to the next step, regardless of the result.
Finalize the iProov attempt:
Use the validateIProovVerifyToken method to finalize the iProov attempt. This step also tells
ReadID server that the iProov token was used and that the server should start polling iProov for
verification results. If you do not perform this step, then the ReadID server will mark the iProov
session as “abandoned” after 30 minutes, regardless of what happened during the previous step. In
addition, the next retrieveIProovVerifyToken would return the same token as the one for the
previous attempt.
As with retrieveIProovVerifyToken, the validateIProovVerifyToken response is always returned via
a callback. The ReadID SDK will poll the ReadID server for a result, for at most 10 times with a
delay of 1 second after each request.
The results of the iProov check are available in the Management portal, in the iProov section of the
ReadID session details.
The main fields to check are:
Passed iProov: If true, then iProov concluded that a real person was present and that their
selfie matches the face image from their document. When using iProov Genuine Presence Assurance,
iProov also concluded that the authentication was done in real-time (as opposed to, for example, an
injected replay). See the iProov website for a more detailed explanation of what their assurances
mean. The corresponding ReadID session field is iProovSession.passed (boolean).
Enrolment image source: The source of the image used for the selfie-check. The image can come
from the chip or from the optical capture of the Visual Inspection Zone (VIZ). The corresponding
ReadID session field is iProovSession.enrolmentImageSource (string).
Any enrolment image source other than NFC is considered to be (much) less reliable. Images that do
not come from the chip are not subject to all of ReadID's verification mechanisms that apply to chip
data. If the image was sourced from the VIZ, we strongly recommend doing a manual check of the image
used for facial verification.
Assurance type: the iProov verification assurance type used during this session, which is either
Liveness Assurance or Genuine Presence Assurance. The corresponding ReadID session field
is iProovSession.assuranceType (string). See the iProov website for a detailed explanation of what
these verification assurances mean.
Optical Orchestration #
Not all identity documents have a (readable) NFC chip. To handle documents without a readable chip, you can combine ReadID with an optical document verification solution. ReadID supports multiple flows that allow you to scan the sides of a document required for optical verification. The results of the optical verification are added to the ReadID session that can be retrieved from the ReadID server.
ReadID supports two optical verification vendors: "Veriff" and "Onfido". The service is only available for the SaaS SDKs.
Optical verification requires that you also use either iProov Enroller (Genuine Presence Assurance) or Basic Face Verifier (Liveness Assurance). If you combine iProov with Veriff, we strongly recommend to use the by Veriff provided cropped face image (if the face image from the chip is not available).

The face image cropped from the VIZ by the ReadID SDK is not a reliable source. The identity document may be manipulated (e.g., face image replaced) or an attacker may feed a different face image to the ReadID server. ReadID does not perform any authenticity checks on the captured image. If you use this option, be sure to verify the results.

Overview
Optical orchestration must be enabled on the ReadID server and implemented within your mobile app.
To enable optical orchestration on the server, login to the Management Portal with a user that is allowed to manage submitter applications and update the following settings:

Enable iProov and configure the allowed sources for the face image.
Enable and configure Veriff or Onfido.

Consult the ReadID Server- or Management Portal Administration Guide for more information or contact the ReadID support if needed.
Before doing optical orchestration in your mobile app, you should:

Implement a ReadID flow that accounts for documents without a readable chip and/or where chip-reading fails. Make sure that the result of the ReadID flow(s) contains one or two VIZ images of the document if you plan to proceed to optical orchestration. You would typically chain one or more VIZOnlyOnePageFlow's and NFCOnlyFlow to achieve this. You can also use the less flexible but easier to use NFCWithVIZFallbackFlow.
Ensure all results are submitted to the ReadID server.
Proceed to optical orchestration when necessary, for example when there are no NFC results at all, but possibly also when verification (in particular clone detection) failed.

Optical orchestration implementation:

Once the ReadID session (including all VIZ data) has been submitted, initiate optical orchestration via (ClientServer)ReadIDSession.verifyOnfido for Onfido or (ClientServer)ReadIDSession.verifyVeriff for Veriff. The ReadID server will not begin the optical orchestration process unless you use that method. If a fatal error is returned, cancel the process or start over by capturing new VIZ images in a new ReadID session.
While the optical orchestration process is running on the server, the app can already proceed with iProov (see iProov Facial Verification). However, when using Veriff, you should wait at least 3 seconds in order to confirm that Veriff is able to provide the face image to iProov. See below for more details.
After iProov was successfully completed and validated, the ReadID session can be finished by calling (ClientServer)ReadIDSession.finish. This will notify the ReadID server that the app will take no further action that can update the resulting ReadID session, allowing the server to finish the session as soon as possible and trigger the session webhook (if configured).

It is typically neither necessary nor good practice to wait more than a few seconds for the optical verification process to finish before going to the next step in your app. Should you choose to wait for a longer period and/or show any status or intermediate results to the user, you can continue to poll the status using the verifyOnfido or verifyVeriff method.

Optical verification can take a long time, typically too long to let users wait for it. At this time, Veriff can take up to 45 minutes to complete and Onfido up to 6 hours.

Note that you must always start optical orchestration first, iProov second. Starting iProov first may cause the ReadID server to finish the session, meaning it is no longer possible to start optical orchestration. This scenario results in a HTTP 409 error response to the verifyVeriff or verifyOnfido call.
Technical implementation details
To start Onfido, call:
try {
final onfidoDecision = await plugin.verifyOnfido(sessionId: sessionId);
// Handle result
} on PlatformException catch (exception) {
// Handle orchestration errors
}
copied to clipboard
To start Veriff, call:
try {
final veriffDecision = await plugin.verifyVeriff(sessionId: sessionId, submissionId: submissionId);
// Handle result
} on PlatformException catch (exception) {
// Handle orchestration errors
}
copied to clipboard
The app should implement the following polling logic when the cropped face image from Veriff is used for iProov (recommended):

Veriff needs up to 3 seconds to provide a cropped face image. Therefore the app must poll repeatedly, with at least a 1 second delay, until either 3 seconds have passed or until one of the following conditions occurred:

The app received a verifyVeriffResponse.veriffResponse.message with value face_crop_not_found_before_retrieval_timeout. In that case Veriff was unable to extract a face image, usable for iProov verification, and a restart of the entire process starting from a new ReadID session is required.
The app received a verifyVeriffResponse.veriffResponse.verification.status. In that case Veriff has reached a verdict. The value status will be either approved, resubmission_requested, or declined. The verification status resubmission_required indicates that a new VIZ capture should be submitted under the same Veriff session. To do so, store the submissionId for later use, perform one or two new VIZ captures in a new ReadID session, then retry optical verification using the saved submissionId as parameter for the verifyVeriff call.


If there was no verdict or error for at least 3 seconds, you may proceed to iProov verification.

If the face image cropped from the VIZ by the ReadID SDK is used for iProov (not recommended), a single call without error is enough to proceed with iProov.
Advanced #
Custom CSCA Master List (client-only) #
Note that we actively maintain the default master list in order to keep it up-to-date. If you replace the default master list with a custom master list, you must ensure to keep the custom master list up-to-date as well.
Embedded, static custom master list (iOS) #
ReadID-UI contains two default master list files to verify NFC data signatures:

CSCA (version/date tbd)
RDW (Dutch Driving Licence)

Custom master lists can be configured by adding your own versions of the files below to your project:

MasterList.crt
MasterList.ml

Embedded, static custom master list (Android) #
The client-only version of the ReadID UI SDK contains a default master list of CSCA certificates used to verify data signatures. The default master list can be overridden by creating your own keystore with your own master list, naming it csca.ks and adding it to the raw resources folder of your application:

raw/csca.ks

Dynamic custom master list #
Flutter does not support changing the CSCA master list at runtime at this time.
ReadID Flutter Plugin Data Model Documentation #
Flow Objects #
Flow objects in Dart are write-only, meaning all properties have setters only. Default values for
properties can be consulted in our native SDK documentation.
Not available at this current time for NFC/VIZ

vizConfirmationScreenConfiguration: n/a
vizResultScreenConfiguration: n/a
isTouchToFocusEnabled: n/a (Android only)

(Abstract) Flow #
Properties

applicationLevelEncryptionPins: List
accessKey: String?
backgroundTimeout: int (TimeInterval on iOS, long on Android)
baseUrl: String? (called baseURL on Android)
dateFormat: DateFormat enum
dateSeparator: DateSeparator enum
instructionsPlayCount: int
isDebugEnabled: n/a (not exposed to Flutter yet)
language: String?
oAuthToken: String? (oauthToken on iOS)
opaqueID: String?
preventSessionCommit: bool
readIDSession: ReadIDSession? (Map?)
readIDTracker: n/a (not supported in Flutter yet)
screenOrientation: ScreenOrientation enum (Map)
shouldAllowScreenshots: bool (Android only)
shouldAskDismissConfirmation: bool (iOS only)
shouldMaskPersonalData: bool
shouldOnlyShowInstructionsOnFirstUse: bool
shouldUsePinning: bool
uiResources: n/a (not supported in Flutter yet)
customBundleName: String (iOS only)

VIZOnlyOnePageFlow #
Properties

allowedPageTypes: List
allowManualCaptureAfterTimeout: int (Long on iOS)
faceImageFeatureRequirement: FeatureRequirement enum
fastCaptureMode: bool
mrzFeatureRequirement: FeatureRequirement enum
mrzValidation: MRZValidation enum
qrCodeFeatureRequirement: FeatureRequirement enum
shouldAllowLoweringQualityRequirements: bool
shouldRequireNoFingerOnDocument: bool
shouldRequireNoGlareOnDocument: bool
shouldRequireSharpImage: bool
shouldPlayShutterSound: bool
shouldShowDocumentSelection: bool
shouldShowTorchButton: bool
shouldShowVIZConfirmation: bool
shouldShowVIZResult: bool

NFCWithAccessControlFlow #
Properties

manualInputMode: ManualInputMode enum
shouldCommitSessionWithoutNFC: bool
accessControlOption: n/a
allowResumeNFCReading: n/a
allowSkipReadingAfterAttempts: int
allowedDataGroupsToRead: List
allowedDocumentTypes: List
extendedLengthAPDUPreference: n/a
nfcResultScreenConfiguration: n/a
shouldCommitSessionWithSkipButton: n/a (iOS only)
shouldPlayShutterSound: bool
shouldReadImages: bool
shouldRequirePersonalNumber: bool
shouldShowDocumentSelection: bool
shouldShowNFCResult: bool
shouldShowTorchButton: bool
shouldShowVIZConfirmation: bool
shouldShowVIZResult: bool

NFCOnlyFlow #
Properties

accessControlOption: AccessControlOption enum
allowedDataGroupsToRead: List
allowResumeNFCReading: bool
allowSkipReadingAfterAttempts: int
documentInfo: DocumentInfo (Map, used as optional constructor parameter)
extendedLengthAPDUPreference: ExtendedLengthAPDUPreference enum
nfcAccessKey: NFCAccessKey (Map, used as required constructor parameter)
nfcResultScreenConfiguration: NFCResultScreenConfiguration (Map)
preventChipSupportDialog: bool
shouldReadImages: bool
shouldShowInstructionCarousel: bool
shouldShowNFCResult: bool
trustedCertStores: n/a (Android only)

Result Objects #
Result objects in Dart are read-only data objects that contain the VIZ and NFC results from a
successful ReadID session.
ReadIDResult #
Properties

vizResult: VIZResult?
nfcResult: NFCResult?

(Abstract) BaseResult #
An abstract base class that holds properties common in both VIZResult and NFCResult.
NFCResult extends BaseResult #
Properties

faceImage: Uint8List?
signatureImage: Uint8List?
Additional properties detailing the outcomes of the ReadID session.

ReadIDSession #
Encapsulated a session where information from a single document is captured. It can contain data
read through NFC as well as optically captured data.
class ReadIDSessionState:
A memento that carries the state of a ReadIDSession at some point in time.
Initializers
init()
copied to clipboard
Create a new session
Instance Properties:

var clientConfiguration: ClientConfiguration?
var clientId: String An identifier that identfies the application that captured this sessions.
var consolidatedIdentityData: ConsolidatedIdentityData? The consolidated identity data.
var creationDate: Date? The date the session was stored.
var customerApplicationReference: String? An opaque value customers can use to store a reference
for their own internal use.
var deviceId: String A unique identifier for the device that captured this sessions
var documentContent: MRTDDocumentContent? Contents of the document, this data is extracted from
the data read from the NFC chip.
var expiryDate: Date? The date when this session expires.
var expiryTimestamp: Int64? The Unix timestamp for the moment the session will expire.
var instanceId: String A unique identifier for the application installation that captured this
session.
var nfcSession: NFCSession Contains data captured from the document using NFC.
var ocrSession: OCRSession? Contains data captured from the document using OCR.
var opaqueId: String? This customer-provided identifier can be used by our customer to
cross-reference this ReadID Session to an app session identifier.
var sessionId: String A unique identifier for the session.
var vizImages: VIZImages? Contains data optically captured from the Visual Inpection Zone (VIZ).
var vizSession: VIZSession?
func restoreState(from: ReadIDSessionState) throws Restore state of a ReadIDSession.
func saveState() -> ReadIDSessionState? Save state of ReadIDSession.

License #
Please read the LICENSE file before using this plugin. Note that the native Android and iOS ReadID
SDKs have a separate license.
Help and support #
You may find your question is answered in the documentation of our native SDKs. This documentation
is available via our ReadID Documentation portal.
For further help with integration of the plugin, please contact support.