5. ACR and AMR values
Summary
NHS CIS2 Authentication ID is currently designed to authenticate most End-Users to Authenticator Assurance Level 3 (AAL3) as defined in the NIST Digital Identity Guidelines for Authentication and Lifecycle Management. This standard sets out three levels, 1 being the weakest, and 3 being the strongest.
ACR is an abbreviation for Authentication Context Class Reference. An Authentication Context Class specifies a set of business rules that authentications are being requested to satisfy. These rules can often be satisfied by using a number of different specific authentication methods, either singly or in combination. Authentication Requests using the acr_values parameter request that the specified Authentication Context Classes be used and that the resulting ID Token should contain an acr claim saying which Authentication Context Class was satisfied. The acr claim states that the business rules for the class were satisfied, it is not intended to indicate how they were satisfied.
AMR is an abbreviation for Authentication Methods Reference. An Authentication Methods Reference identifies an authentication method used in performing an authentication.
This section describes the ACR and AMR values supported by NHS CIS2 Authentication, further information on how these may be used to manage an application session is given in the Session Management section.
Authentication Methods
At the time of writing the NHS CIS2 Authentication offers a variety of authentications at different levels.
AAL3
An AAL3 authentication provides very high confidence that the claimant controls authenticator(s) bound to the End-User's account. This is based on proof of possession of a key through a cryptographic protocol and requires a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device may fulfil both these requirements e.g. a smartcard with a passcode.
| Mechanism | Description |
|---|---|
| iOS CIS2 Application |
The iOS CIS2 Application provides an authentication solution for users of iPads. The application allows an End-User's identity to be registered on the iPad, which generates a private key in the iPad's secure enclave that can only be released by an End-User biometric factor e.g. one of their fingerprints. Authentication occurs by NHS CIS2 Authentication requiring the CIS2 Application to sign a random challenge with the End-User's private key which can only be achieved by presentation of the End-User's biometric factor. Only one End-User identity can be registered on an iPad. |
| Windows Hello |
This solution provides a mechanism by which an End-User's identity can be registered on a Windows 10/11 device that supports Windows Hello. It utilises the FIDO2 capabilities of WHfB to create a private key in the device's Trusted Processing Module (TPM) which can only be released by the End-User (using either a PIN or a biometric). Authentication occurs by NHS CIS2 Authentication performing FIDO2 authentication requiring the End-User's to release their private key using either their PIN or a biometric. This solution is restricted to WHfB devices that have a physical TPM and that are under the sole control of a single End-User. |
| Smartcards using CIS1 Identity Agent |
This solution provides a mechanism for users of smartcards that leverages the existing Identity Agent (IA) solution without the Replying Party web application having to interact directly with the IA or CIS authentication APIs. This solution is restricted to devices on the HSCN network and requires the installation of the new NHS Credential Management Application in addition to the IA. |
| Smartcards using CIS2 Identity Agent |
This solution provides a way of using the existing smartcards with a CIS2 Authentication native solution, that does not require HSCN. This requires v3 or above of the IA/CM |
| Security Keys | These small security keys contain a hardware security module that can be used to store credentials using the FIDO2 process. They can be used on a range of devices (computer, laptop, tablet, mobile) via USB/Lightning/NFC and are unlocked using either fingerprint or passcode |
AAL2
An AAL2 level authenticator provides Multi-Factor Authentication, but is not hardware bound (to the single device), or cryptographically secure. Clients should consider carefully with their end-users if this lower level of authentication is appropriate to their use case.
| MS Authenticator TOTP | This basic username, password and 2nd factor code allows users on almost any device to access applications at a lower security level. For a user, RAs register an email address from an approved domain, set a password and create a code generator on MS Authenticator. When authenticating, the user enters the username, password and then the current code. |
| NHSmail (private beta) | This basic username, password and 2nd factor code allows users on almost any device to access applications at a lower security level. Organisations in the private beta will have guidance on how their users can register NHSmail as an authenticator. When authenticating, the user is redirected to the NHSmail login screen where they enter their credentials and complete a time-based MFA check. |
ACR values
The ACR values appear in two parts of the authorization code flow, and in the context of NHS CIS2 Authentication services these are:
- request, optionally, what type of authentication you want to take place (e.g. smartcard)
- in the returned ID Token the ACR claims indicates the acr value that was used
The OpenID Connect specification only contains the one defined ACR value of "0". The value "0" indicates the End-User authentication did not meet the requirements of a level 1 authentication e.g. for example an authentication using a long-lived browser cookie. Authentications with level 0 SHOULD NOT be used to authorize access to any resource of any monetary value and by extension SHOULD NOT be used to access clinical systems.
The specification states that use of other values are to be defined between the parties using the claim.
Requesting specific ACR values
The NHS CIS2 Authentication fully supports the following ACR values:
| ACR Value | Description |
|---|---|
| AAL3_ANY (default) | Setting the acr_values parameter to AAL3_ANY in the Authentication Request guarantees that an authentication mechanism will be used that meets the criteria for an AAL3 authentication. The authentication mechanism selected will depend on the capabilities of the operating system and browser of the device that the End_User is using. In scenarios where more than one mechanism is supported the End-User will be able to set a preferred mechanism. The resulting authentication_assurance_level claim in the ID Token will be 3 |
| AAL2_OR_AAL3_ANY | The user can select any of the AAL2 or AAL3 Authenticators. The resulting authentication_assurance_level claim in the ID Token will indicate the actual level achieved. |
| AAL2_ANY | The user can select any of the AAL2 level authenticators. The resulting authentication_assurance_level claim in the ID Token will be 2 |
If the acr_values parameter is not provided in the Authentication Request then a value of AAL3_ANY will be assumed depending on the environment in which the request is being made.
Following a successful Authentication Request the resulting ID Token will contain an acr claim matching that provided (or assumed) for the original request.
Multiple ACR values provided as a space separated list, however as per the OIDC specification the first matching valid value will be selected, they are not combined.
Additional ACR values that can be requested
NHS CIS2 Authentication offers support for the following additional ACR values, however these are subject to change at any time and SHOULD NOT be used. Requesting a specific authenticator limits the authenticator choice for an end user and goes against National Registration Authority Policy in restricting access to National Clinical Systems.
Use of these ACR values is subject to the following caveats:
- Use of an ACR Value inappropriate for the End-User's device may cause the authentication to fail.
- If the End-User is using more than one Relying Party web application and they use different ACR values then the End-User may experience multiple authentication events.
- Providing one of these ACR values will skip the end user prompt to select an authenticator.
Should a Relying Party identify a need to use a specific authentication mechanism they should contact [email protected] to discuss whether the use of an additional ACR Value can be supported in their use case.
AMR values
NHS CIS2 Authentication will return one of the following AMR values in the ID Token:
| AMR Value | Description |
|---|---|
| IOS | The user was authenticated using the iOS CIS2 Application by NHS CIS2 Authentication. |
| FIDO2 | The user was authenticated using FIDO2 via Windows Hello by NHS CIS2 Authentication. |
| N3_SMARTCARD | The user was authenticated using a smartcard via the legacy CIS1 Identity Agent. |
| CIS2_SMARTCARD | The user was authenticated using a smartcard via the new CIS2 Identity Agent. |
| TOTP | The user was authenticated using the MS Authenticator TOTP flow. |
| THIRDPARTY_NHSMAIL | The user was authenticated using the NHSmail flow. |
All chapters
Last edited: 5 February 2025 2:51 pm