ID Verifier FAQ

The ui_locales parameter sets the language shown in the web browser UI during the identification flow. It is not used in the SDK’s internal UI.

No. The SDK uses the device OS language setting, not the ui_locales value. This means the parameter only influences browser-based content, not native UI.

Yes. Language synchronization between the SDK and backend session is a planned feature for a future SDK release.

Despite the plural name, only a single locale value is supported (e.g., nb-NO).

Supported values are listed in the official developer documentation. Common examples include:

en-US – English (US)
nb-NO – Norwegian (Bokmål)

The SDK UI reflects the language of the user's mobile OS. To support localization:

Add translated strings.xml files for each language you support.
The SDK will automatically select the correct language based on the OS.

To initialize the SDK, you must call the NtdrSDK.load(key, version) method with a valid SDK key and version.
Example:

java

CopyEdit

NtdrAPI api = NtdrSDK.load("DEVICE_IDENTIFIER", NtdrSDK.VERSION);

The SDK key is a static device identifier string, typically provided by Nets.
In the sample app, these are the default keys:

Android:
private final String DEVICE_IDENTIFIER = "AND0000000000000";
iOS:
private final String DEVICE_IDENTIFIER = "IOS0000000000000";
If you are integrating into production, contact Nets to request a production-ready key.

The version identifies the SDK implementation version. It ensures compatibility with the backend and correct handling of protocol features. It is usually provided as NtdrSDK.VERSION.

Use the SDK’s built-in UX to present document type options. From the backend, initiate the CIBA-flow with:

• ntdr-app-doclist: true

• ntdr-doc-types: "P, I"

When ntdr-app-doclist is set to true, the user is shown a screen to select a document type, and the animation adapts based on the selection.

No, selecting the ID type externally of the SDK is not supported.

The claim "authentication_result" returns either:

• "pass" – all ID checks were successful.

• "fail" – one or more checks failed.

It explains why authentication failed. Possible values include:

• STATUS_BAD_FACEMAP – Facial recognition was not completed

• STATUS_BAD_BIODATA_AUTH – SDK authorisation failed

• STATUS_BAD_BIODATA_EXPIRY – Document expiration criteria not met

• STATUS_BAD_BIODATA_DOCTYPE – Document type mismatch

• STATUS_BAD_BIODATA_ISSUER – Document issuer mismatch

• STATUS_BAD_CHIPVERIFICATION – Chip verification failed

• STATUS_BAD_CLONEDETECTION – Clone detection failed

• STATUS_BAD_DOCUMENTHASHES – Document hashes do not match signature

• STATUS_BAD_DOCUMENTSIGNATURE – Signature verification failed

• STATUS_BAD_COUNTRYSIGNERCHAIN – Document trust anchor incomplete

Check the "acr" claim in the ID token:

• urn:eident:cert:eidas:substantial → eIDAS Level 3 (DIGG Level 3)

• urn:eident:cert:eidas:high → eIDAS Level 4 (DIGG Level 4)

Yes, use it to specify the required assurance level. It affects which verification checks are enforced.

• High: All key checks must pass — CHIPVERIFICATION, CLONEDETECTION, DOCUMENTHASHES, DOCUMENTSIGNATURE, COUNTRYSIGNERCHAIN.

• Substantial: More lenient — can accept expired documents within limits and allow documents without clone detection.

Yes, for all scanned documents. But its result is only critical if ACR high is requested. If clone detection fails in that case:

• authentication_result=fail

• result_explanation=STATUS_BAD_CLONEDETECTION

In the ID token, via the personal_number claim.

In the claims:

• primary_identifier

• secondary_identifier
  All in Latin characters.

Via the birthdate claim in the ID token.

Through the authentication files accessible via auth_files_url.