Quality of Authentication QoA Dieses und andere . . . — eIAM, Identity & Access Management des Bundes

Quality of Authentication QoA

Dieses und andere technische Dokumente sind nur in Englisch verfügbar, um internationale Zugänglichkeit zu gewährleisten und Ressourcen zu sparen.

Ce document et d'autres documents techniques sont disponibles uniquement en anglais pour garantir l'accessibilité internationale et économiser des ressources.

Questo documento e altri documenti tecnici sono disponibili solo in inglese per garantire l'accessibilità internazionale e risparmiare risorse.

Use the checklists at to evaluate the needs of your application!

Note: The abbreviation QoA is assigned differently in the ICT specification I050.

Introduction

When a natural person is authenticated by an ICT system, this person presents the ICT system with credentials, which can be read and interpreted by the ICT system. Credentials are often artifacts such as passwords, differently generated one-time codes, and (other) crypto artifacts. Biometric features can also serve as credentials, which in turn result in crypto artifacts.

The use of credentials represents a transaction that establishes the reference to the electronic identity of the natural person for a limited duration (session), the electronic identity in turn represents the natural person itself.

The first dimension of the quality of an authentication (of a login transaction) is the quality of the credentials used: A login using a password and a second factor such as mTAN is better than a login using a password without a second factor, crypto artifacts are better login factors than transparent artifacts such as one-time codes, and so on. In general, hardware-based methods usually lead to higher security than software-based methods.

The second dimension of the quality of an authentication is the quality of the verification of the identity of the natural person who is equipped with credentials. The aim is to ensure that, in connection with the credentials issued, the true data of this person are registered and stored and that the credentials are issued precisely and exclusively to this person (also referred to as linkage quality) with the aim that this person can be found again (in the event of recourse). The data basis in the verification process is usually the presentation of an official photo ID and the registration of the information contained on it, in particular the ID number, which can enable tracing via population registers. On the one hand, the quality of the identity verification is dichotomous, it takes place or not, which leads to the distinction between verified and unverified (self-registered) electronic identities; within the verified electronic identities, on the other hand, there are differences in the quality of the verification processes.

There are various taxonomies that map these two quality dimensions of authentications* into one-dimensional quality statements. These taxonomies have in common that they exclude the combination of credentials of low quality with verifications of high quality, in other words, it makes no sense to let a verified electronic identity used only with a password as credentials count as a high-quality authentication.

*The term quality dimensions of electronic identities can also be used. Since electronic identities are often equipped with multiple credentials of different quality, the designation quality dimensions of authentications is more precise; the resulting quality is affected by the credentials effectively employed by the user in an authentication. Furthermore, in order for the quality contribution of the credentials for an authentication to take effect, the adequate design of the technical binding of the subsystems for establishing the trust chain (trust) is a prerequisite. If this prerequisite is not met, the quality level to be assigned for the authentication concerned is lower than that expected from the dimensions credentials and degree of verification.

The governing taxonomy in eIAM is the multi-level AuthContextClass referred to as Quality of Authentication QoA, applications that obtain authentication services from eIAM require a minimum AuthContextClass to be satisfied in runtime communication to eIAM, i.e. a matching login process is enforced. The levels of the AuthContentClass of eIAM are:

guest (10): not carried in the dtable below; unexplained, only mTAN, no data space may be established in the target application and no recognition, so only captcha character.
weak (20): unverified, a soft token (password).
normal (30): unverified, verified in enterprise context respectively nHEC+, two soft tokens (password with mTAN or Authenticator app).
normalxistent (35): not verified but reference to a registry, two soft tokens.
normalverified (40): always verified, two soft tokens.
strong (50): verified, soft token plus hardware-based token (password and Vasco token or Mobile ID or FIDO-Token).
verystrong (60): verified with certified process, soft token plus hardware-based token of high cryptographic quality based on certified processes (password and smartcard).

All other taxonomies must subsequently be mapped to this taxonomy governing in eIAM, see table below.

Mapping table

The scales always combine two dimensions, namely verification quality with credential quality, whereby the dimension that is worse to assess wins.

Which QoA is necessary for which Schutzstufe (formerly Schutzniveau) see

QoA by eIAM	LOA by eCH170 v2.0	AGOVaq ()	Credentials	Identity verification
10	n/a	n/a	mTAN	SMS mTAN only, special feature of ePortal
20	1	n/a	Password only	none
30	2 is often mentioned, but is not achieved due to lack of register reference	100	2FA. Low quality second factors e.g. SMS-mTAN allowed.	None (also no register reference)
35	2 or close to 2	200	Delivery of an onboarding code letter+2FA. Low quality second factors e.g. SMS-mTAN allowed.	None, only with automatic address verification before sending a paper letter with onboarding code.
40	2	n/a	E.g. Kerberos or 2FA. Low quality second factors e.g. SMS-mTAN allowed.	Assignment to an existing subject, but without (systematic) photo ID check, e.g. HR onboarding -> Kerberos.
50	For Confederation almost 3, but not for cantons (fam. 2,5)	AGOVaq300	2FA, at least one of them cryptographically hardened e.g., Password+Mobile ID, FaceID+MobileID, Password+dedicated cryptographic Access App, FaceID+dedicated cryptographic Access App,Password+FIDO security key, Biometrics+FIDO security key (FaceID stands here as an example for biometric methods of a certain quality). The naming of the dedicated cryptographic Access App in AGOV is AGOV Access App und in FED-LOGIN its the FED-LOGIN Access App.	Control and registration of an official photo ID in a well-defined process. For FED-LOGIN: incl. video identification, if this is based on HR data. For CH-LOGIN: incl. video identification if based on an invitation. For AGOV: Videoident, postal BmID-Service, cantonal LRA-Counter
51	For Confederation almost 3, but not for cantons (fam. 2,5)	AGOVaq400 is same as AGOVaq300 but has additional AHV-No. validated	cf. AGOVaq300	cf. AGOVaq300
55	3	AGOVaq500	CH e-ID	CH e-ID
60	4 (eIAM almost, SSO portal entirely)	n/a	Regulated crypto hardware and crypto algorithms, e.g. smart card of the SG-PKI.	Control and registration of an official photo ID in a certified process.

Link to epic QoA representation: Quality of Authentication QoA