Introduction

The Quality of Authentication (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 QoA by the application - or implicitly by the requested Level of Trust - the user has to fulfill no verification (QoA1), fulfill either the manual identification or video identification method (QoA2) or the requirements from QoA2 and the API verification method (QoA3).

QoR Claims

In the id_token you will get a list of QoA’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.