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 completedSTATUS_BAD_BIODATA_AUTH
– SDK authorisation failedSTATUS_BAD_BIODATA_EXPIRY
– Document expiration criteria not metSTATUS_BAD_BIODATA_DOCTYPE
– Document type mismatchSTATUS_BAD_BIODATA_ISSUER
– Document issuer mismatchSTATUS_BAD_CHIPVERIFICATION
– Chip verification failedSTATUS_BAD_CLONEDETECTION
– Clone detection failedSTATUS_BAD_DOCUMENTHASHES
– Document hashes do not match signatureSTATUS_BAD_DOCUMENTSIGNATURE
– Signature verification failedSTATUS_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
.