Quality of Authentication (QoA)

The QoA concept deals with the various QoA classes and their definition and classification. Each authentication method (credentials with or without second factor) corresponds exactly to a defined QoA class.

With the specification of the corresponding QoA class in the SAML/OIDC federation protocol, the following advantages result:

A business application does not have to worry about the complex configuration of the various authentication methods.
It only has to be decided which QoA class is desired or required for the business application to be integrated. By specifying the corresponding QoA class in the federation protocol, it is automatically ensured that the user is offered all permitted authentication methods that at least correspond to this QoA class.
New authentication methods, which are included in the QoA concept, are thus automatically available without having to adapt the application.
The introduction of new authentication methods thus becomes transparent for the business application.

: IdPs FED-LOGIN/BYOI and QoA (Credentials/Verification Types)

IdP+credential(s)+verification type = Quality of digital identity

Both the authentication procedures (credentials) used for a login and the degree of verification (verification type) of an identity are decisive for the quality of a digital identity. eIAM describes this as Quality of Authentication (QoA).

For the QoA40, 50 & 60, the underlying digital identity is not simply registered itself, but verified (surname, first name, date of birth, type of ID and ID number). Verified electronic identities make it possible to trace who has been equipped with them and thus, if necessary, to take recourse against these persons.

Identity checks are always based on valid official photo IDs and the simultaneous presence of the person to be checked. The ID cards are registered

In which cases must identities with QoA 40, 50 and 60 be used?

Access to ICT resources of the Federal Administration in an enterprise context (for internal and external employees and partners): The minimum requirement is QoA40.
Access to data with increased protection requirements. According to the current zone policy, QoA50 is required. This is only possible with Hardcrypto tokens such as the smart card*, the Access App's or by means of FIDO security keys and Mobile ID with VIPS.
*The smart card requirement (QoA60) may only be used in justified exceptional cases after consulting the FCh DTI.
Requirement of the business process to be able to uniquely identify the acting person (recourse capability): The minimum requirement is QoA40.
In certain cases, this can also be done by the target application, for example by uploading a copy of an ID card to the application.

Different QoA classes per eIAM stage

At the customer's request, the flexibility of different QoA classes per stage was implemented in eIAM. If a customer requires a lower QoA in a non-productive environment, this can be implemented in compliance with the following rules.

Rules for the quality of authentication (QoA) ▼

Responsibilities and competences
- The protection requirements of the application with the resulting [linktext:protection level] define the minimum quality of authentication (QoA class) of the productive environment.
- The application owner determines the required minimum quality of authentication (QoA class) for access to their application instances (PROD, ABN and REF) with the responsible CISO.
Exceptions in non-productive environments (ABN/REF)
- If different QoA requirements apply in a non-productive environment, this must be confirmed in writing (signed mail) by the responsible ISBO to the eIAM SIE.
- This exception is only permitted if no data with a high protection requirement is processed.
Request for QoA by the relying party
- An eIAM-integrated relying party can either request the minimal QoA class:
  - during the runtime in the federation request to eIAM.
  - specify it during integration (definition time) in eIAM.
Reject the federation request if no QoA is specified
- If the relying party does not specify a QoA either at definition time or at runtime, eIAM rejects the federation request.
Enforce the highest QoA requirement
- If a higher QoA has been defined at definition time, eIAM MUST also enforce it if the relying party allows a lower QoA at runtime.
- If a higher QoA is required at runtime than at definition time, eIAM MUST also enforce the higher QoA.
QoA in protected zones
- If the relying party is operated in a zone with increased security requirements (e.g. SZ+ Basic), eIAM MUST fulfil the QoA of this zone.
- A lower QoA cannot be permitted either at definition time or at runtime, as the RP-PEP (Relying Party Policy Enforcement Point) regulates access.
Uniform integration pattern for productive environments
- If a zone with higher QoA requirements is used in the productive environment, the same integration pattern (with RP-PEP) MUST be used in all operating environments of the relying party.
- Even if no RP-PEP zone is required at lower integration levels (ABN/REF), eIAM enforces the productive QoA requirements in all environments.
QoA displayed in the token
- eIAM MUST display the QoA in the token to the relying party.
- The relying party MUST ensure that the QoA identified in the token meets its requirements.

Login methods (Credential and verification methods)

FED-LOGIN Login Methods

BYOI: CH-Login Methods ▼

The CH-LOGIN is a 2-factor (username/password and FIDO security key/mobile ID/mTAN/AuthApp) identity provider service provided by the eIAM service. CH-LOGIN can be used for a wide range of Federal Administration applications. This enables the offices to provide internal and/or external users with several login procedures for their specialised applications.

Verification types:

mTAN / Auth. App ▼

Logging in with a password and a second factor, such as mTAN (SMS) or an Authenticator app (OATH), is an alternative method, but it is rated as less secure (QoA40). As a result, access to certain applications may be denied. We therefore recommend registering for Mobile ID to ensure the best user experience.

Mobile ID / FIDO security key ▼

Mobile ID
The Mobile ID is a certificate that is stored on the SIM cards (Subscriber Identity Module, incl. eSIM) of (currently only Swiss) mobile telephony providers (for providers, see ). It can be used as a credential and is registered in advance by the user in self-service on MyAccount. The target system that requests a means of authentication and identity verification and accepts the Mobile ID for this purpose sends a dedicated push message to the mobile device that uses the corresponding SIM card. The end user must then enter a password on this mobile device in order to transmit the Mobile ID to the requesting target system.

Important note
The Mobile ID in the context of the Federal Administration is not aimed at the general public. It can only be used within the Federal Administration by invitation. You will receive the invitation from your specialist contact at the Federal Administration together with a so-called MIO code (Mobile ID onboarding code).

Security key
Information about Security keys

The use of the Mobile ID and/or a FIDO security key as a credential does not automatically lead to a verified electronic identity; video identification must also be carried out for this.

Video identification ▼

The video call is made in the browser of a PC or mobile phone, so no special software needs to be installed / available. During the video call, a human agent from the mandated video identification company (currently Intrum, operating hours: Monday to Saturday from 08:00 to 17:00) checks the authenticity and validity of the ID, the coherence of the photo with the face of the person present and the physical presence of the person in the video call

Complete list of countries and authorised identification documents Country list

Detailed information: Video identification

BYOI: AGOV Login Methods ▼

AGOV access Apps
The AGOV login works via smartphone app or security key (FIDO). The choice is left to the end user. Link to instructions: AGOV - Register

Verification types:

Video identification ▼

Complete list of countries and authorised identification documents Country list

Note
The costs of the video identification check are charged to the owner of the target application, whereby an identity check is valid for 5 years for the entire AGOV ecosystem and does not have to be carried out several times.

LID ▼

Swiss Post service: personal identification and production of a copy of ID at the front door (letter with ID check).
Accepted ID cards

Valid passport
Valid identity card
Foreigner's identity cards issued in Switzerland

Factsheet from Swiss Post: Letter with ID chek (LID)

AGOV Counter ▼

AGOV end users can have their identity checked by visiting a cantonal AGOV counter, if the canton offers such counters, by presenting a valid ID. The cantons decide which foreigner's identity cards they authorise.

Note
AGOV is the new CH-LOGIN, i.e. an identity provider of the Federal Administration's standard ‘Identity and Access Management’ service. AGOV will be available for productive use from January 2024 and will replace CH-LOGIN in due course. Infolink: AGOV the new CH-LOGIN

Specifications

SAML QoA Specification
OIDC QoA Specification
Detailed information about QoA (internal access only):