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.
Graphic with QoA level for FED-LOGIN and BYOs
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) ▼
×

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

Specifications

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