Last update:
Identity / Authentication assurance levels
Aug 21, 2026
For the applications that uses CMS Interoperability Framework and/or TEFCA, it is important for the applications to obtain the required identity / authentication assurance levels before using their capabilities. This section explains how to validate the current assurance levels of the user, and how to obtain the required (i.e. higher) assurance levels if their current levels do not satisfy the requirement.
Validating the current assurance levels
IAL (IAL1 / IAL2)
For IAL, the validation requires two steps:
- When the applications start OIDC, OIDC authorization endpoint parameter scope should include verified_claims.
- After the applications obtain ID token, validate verified_claims.verification.assurance_levels array as you see below.
- Regarding types of IAL, please see the previous Authentication context class reference (ACR) section.
- When none of IAL in the list above is assured for the user, ID token would not contain verified_claims claim in JWS payload and it implies IAL1 without PBIC or DBIC.
AAL (AAL1 / AAL2)
For AAL, the validation method depends on how the user is authenticated on the applications.
Web app & mobile app HSID OIDC authentication
For these cases, HSID OIDC Authentication is performed right before getting into the applications, therefore, the applications can check amr (Authentication Method Reference) claim (array) in JWS payload of ID token. To satisfy AAL2, one of the following amrs is required:
- otp (Phone SMS / Call OTP)
- wa (WebAuthN – Passkey)
If none of them is included, the user’s authentication session is AAL1.
Mobile app biometrics authentication
When Mobile App Biometrics Authentication is performed before getting into the applications, HSID OIDC Authentication is not executed. Since performing only biometrics authentication does not satisfy AAL2 requirement, this case is always AAL1 unless the unexpired existing mobile app session obtained and validated MFA (see the next section and Mobile Application AAL2 ) in its session lifetime.
Note: Mobile App Biometrics Authentication currently utilizes long-lived refresh token, which can be used to issue a fresh ID token. However, this fresh ID token contains AMRs when the original refresh token was issued (with HSID OIDC – which happened long time back). Therefore, amr check should not be used to determine Mobile App Biometrics Authentication’s AAL.
Obtaining the required assurance levels
When the validated assurance level does not satisfy the required assurance level, the applications can request additional identification / authentication to satisfy the required level. This can be done by requesting acr_values with the standard OIDC, and it is called Step-up AuthN & Identification (Portal High Risk Transaction) flow. For the details, please refer to this section.
It is OIDC protocol, therefore at the end, the applications retrieve ID token. The applications are responsible to re-validate ID token (see the previous section) to confirm that the requested assurance level is obtained.
Next:
OpenID Connect endpoints
Share additional feedback to help us improve.
0/255
|
Powered by Aikyam @2025 All rights reserved
+1 866 451 2735
+1 866 451 2735
+1 855 819 5909