Introduction

The Quality of Registration (QoR) defines how confident we are in the subject to be who he claims to be. If he simply registered without any verification steps, he has a low QoR / LoR. If we verified his identity against a third party system or by manually checking his passport, a higher QoR can be issued.

Validation methods

To validate the Quality of a users registrations, there are various verification methods available.

Manual Identification

The user has to be validated manually. To initiate that process, a document will be generated with a unique QR code. He than has to present himself physically at a government office, at the post office, or wherever you would like to perform the verification. The verify-er then can simply scan the QR code and compare the registered data with an official document such as a passport, that the user has to present.

Video Identification

With the video identification method, the user can scan a QR code and then perform a video identification process. Within that process, the user has to pass a livenes check and scan an official document.

API Identification

The entered data can be verified against any existing API such as the ZAS (Zentrale Ausgleichsstelle / AHV) system, given you have access to such a system.

Quality of Registration to verification methods assignment

Within the configuration, you can define which verification methods have to be passed, for which quality of authentication. There is an option to AND or OR combine various methods. Whenever there is an OR combination, a selection will be presented to the user, so that he can choose his preferred method. Below is a visual sample configuration:

Depending on the configured or requested QoR by the application - or implicitly by the requested Level of Trust - the user has to fulfill no verification (QoR1), fulfill either the manual identification or video identification method (QoR2) or the requirements from QoR2 and the API verification method (QoR3).

QoR Claims

In the id_token you will get a list of QoR’s the the user has passed in the fulfilled_qors claim.

Note: This is independent from the arm_values which only contains the passed LoT and QoR definitions requested by the current application. A user could login with a QoA1 to your application, but also would have passed QoA2. Since this was not requested by the application, it's not passed into the arm_values but into the fulfilled_qors.

Configuration

There is currently no configuration user interface for this. The configuration is linked to the Level of Trust and stored in the servicecorelogin_quality_of_registration table. There you can define different QualityOfRegistrationSteps which have to match the documented enum below. In upcoming versions there will be a user interface for this configuration.

public enum QualityOfRegistrationSteps
{
    Dummy,
    None,
    AutoOrManual,
    AutoOrManualAndAhv,
    Auto,
    AutoAndAhv
}

Hint: Dummy=0 // None=1 // AutoOrManual=2 // AutoOrManualAndAhv=3 // Auto=4 // AutoAndAhv=5

For example: if you want only None, Auto and AutoAndAhv your servicecorelogin_quality_of_registration needs only 3 rows with the steps 1, 4 and 5.

Hint: The column “name_key” has no functional behavior despite linking to the corresponding translation in the language file to show the correct translation in the UI.