Level of Trust - LoT
Introduction
The Level of Trust (or Level of Assurance) describes how trustworthy a digital identity is. There are various industry standards that try to define rules on how that trustworthiness has to be checked, such as the ISO/IEC 29115 or the eCH 170 Standard. They all have in common, that the Level of Trust is build upon multi dimensional rules, such as the Quality of Registration (QoR), the Quality of Authentication (QoA) and other factors, such as operational requirements. Within the CoreOne Suite, you can define and configure your own definition of the the Level of Trust, depending on your needs. This is generally done by combining the Quality of Registration (QoR), the Quality of Authentication (QoA) and other optional checks.
Level of Trust = Quality of Authentication + Quality of Registration + additional checks
Terminology
Quality of Authentication QoA
The Quality of Authentication (QoA) or Level of Authentication (LoA) defines how strongly the subject / user has authenticated. If the user simply authenticates with a username and password, a low QoA / LoA is issued. If a user uses a more secure authentication such as a second factor, a higher QoA / LoA is issued.
Quality of Registration QoR
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.
Level of Trust LoT
By defining various Level of Trusts we can now assign various criteria to that definition. In most cases it’s enough to build a matrix of QoA and QoR as shown below, where the vertical axis is the QoA and the horizontal axis is the QoR.
 | Self declared identity | Digitally verified identity | Digitally verified identity + check against social security registry |
---|---|---|---|
Password Authentication | LoT1 | LoT1 | LoT1 |
Password and MFA Authentication | LoT1 | LoT2 | LoT2 |
Hardware Based Authentication with certified hardware | LoT1 | LoT2 | LoT3 |
But in more complex scenarios, there might be additional checks. A simple matrix does no longer solve the issue. We therefore treat the QoR as a subset of multiple criteria that have to be fulfilled to it’s defined level. So a better example would be:
 | QoA | QoR | Failed logon attempts |
---|---|---|---|
LoT 1 | QoA 1 or higher | QoR 1 or higher | - |
LoT 2 | QoA 2 or higher | QoR 2 or higher | Less than 100 failed logon attempts |
LoT 3 | QoA 2 or higher * | QoR 3 | Less than 10 failed logon attempts |
Example Level of Trust definitions
The following are a few example Level of Trust definitions.
Definition 1
LoT | QoA | QoR |
---|---|---|
LoT 0 | PWD + MFA | QoR 0 (basically none, self registered) |
LoT 1 | PWD + MFA | QoR 1 (User passed auto ident or postal ident) |
LoT 2 | PWD + MFA | QoR 2 (User has been checked against social security registry) |
Definition 2
LoT | QoA | QoR |
---|---|---|
LoT 1 | PWD | QoR 1 (basically none, self registered) |
LoT 2 | PWD + MFA | QoR 2 (User passed auto ident or manual ident) |
LoT 3 | PWD + MFA | QoR 3 (User has been checked against social security registry) |
Custom Level of Trust
Applications can request a certain LoT that is not the one specified for the client. It may be useful to protect actions that require a higher security profile.
This can be achieved by setting urn:coreone:authentication:lot:value:
acr value during authentication request.
https://server.example.com/connect/authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fc
&acr_values=urn%3Acoreone%3Aauthentication%3Alot%3Avalue%3Aput_your_lot_acr_here [which is url-encoded urn:coreone:authentication:lot:value:put_your_lot_acr_here]
After a successful authentication, a token will be issues and the acr
value will be set to the requested LoT. You can find more information on that here Quality of Authentication (QoA) | ACR and AMR
© ITSENSE AG. Alle Rechte vorbehalten. ITSENSE und CoreOne sind eingetragene Marken der ITSENSE AG.