Creating an ID validator configuration
Grant roles
To see the ID validator section in the Admin UI, assign the required role(s).
- Open User Search & Setup → User Search.
- Search for your user → ⋮ → Edit User.
- Under Groups & Roles → Cidaas Admin, add
IDVAL_ACCOUNTANT. - Save.
If ID validator is still missing from the sidebar:
- Reload with
F5 - Log out and back in
- Contact support if it still does not appear
Create a configuration
An ID validator configuration (setting) defines how a validation runs.
You can maintain multiple configurations for different projects, departments, or assurance levels.
Open ID validator → ID validation Settings → Create a configuration.
General section (required)
| Attribute | Description |
|---|---|
| Configuration ID | System-assigned unique ID |
| Configuration Name | Label in the overview |
| Configuration Description | Longer description for admins |
| ID validation Mode | Security profile for this setting — see below |
| Theme | Branding of the WebApp |
| Redirect URLs | Allowed post-validation redirect targets |
Choosing the ID validation Mode
The mode is the most important field in this form. It sets:
- which process steps are required (document, face, liveness, QES, …)
- how deep security checks run
- how many retries the user gets
- whether a successful result may be stored for reuse
Do not guess the mode from the dropdown alone.
Use the Verification Modes guide for clusters (Ident / Age / Onboarding), the full matrix, and a decision table. Then come back here to create the configuration.
| Goal | Example mode |
|---|---|
| Simple document check | IdentCard |
| KYC with face + liveness | IdentLight |
| eIDAS / QES | IdentEidas |
| Age gate | AgeCheckLight / AgeCheckEssential |
| Onboarding with context | OnboardingLight / OnboardingEssential |
Optional layers below (consent, prevalidation, data matching) sit on top of the mode — they do not replace it.
Consent configuration
Legal processing of ID validation data requires user consent. Two patterns are supported:
Consent before validation (API)
If consent is disabled in the configuration, you must send consent in the create-process API call. The Admin UI shows a warning:
See the API documentation.
Consent during validation (WebApp)
Enable the consent toggle, then add consent entries with +.
| Attribute | Description |
|---|---|
| Name | Internal label (admins only) |
| URL | Public page with the full consent text — you must keep it reachable and up to date |
| Mandatory | Required vs optional consent |
| Display Text in Webapp | Text shown to the end user (at least one locale required) |
Your consent text should cover, at minimum:
- which personal data is collected
- how it is processed, stored, and protected
- legal basis (e.g. GDPR Art. 6)
- data-subject rights
- retention periods
- third-party processors
Ask us for templates your legal team can review.
Document data matching
Document data matching compares reference values you already know about the person with values extracted from the scanned ID document.
How it works
- In the Admin UI you enable the fields to verify (e.g. given names, surname, date of birth).
- When your backend creates the process, you send those values under
custom_attributes(keys must match the configured field keys). - After document scan, the ID validator extracts the same attributes from the document (OCR / MRZ).
id-val-srvcompares each configured field (typically exact string equality).- The match outcome is stored on the case and returned via webhook / result API.
When to use it
| Scenario | Recommendation |
|---|---|
| eIDAS / high-assurance KYC / onboarding | Enable — ensures the presented document belongs to the expected person |
| Age gate with pseudonyms | Often skip — authenticity (+ optional face) is enough; names may not match the account |
Recommended for: IdentEidas, high-assurance Ident, onboarding.
Often less relevant for: age verification with pseudonymous accounts.
The editable key must be supplied when creating a process. Payload examples: Integration Guide · API documentation.
Document data matching = your API data vs. document text/MRZ.
Face matching = live face vs. document portrait (controlled by the mode).
Prevalidation configuration
Collect or confirm business-context fields before document capture (contract number, employee ID, date of birth, …). Useful as an extra gate for eIDAS and sensitive onboarding.
| Attribute | Description |
|---|---|
| Key | Must be sent with a value when creating the process |
| Type | Expected primitive type |
| Mandatory | Required vs optional |
| Translations | Labels shown in the WebApp |
Prevalidation is recommended for IdentEidas and OnboardingEssential.
See Verification Modes for which modes treat it as optional vs recommended.
Next steps
- Verification Modes — confirm you picked the right profile
- Webhooks — receive status updates
- Integration Guide — create processes via API