Skip to main content

5. ACR and AMR values

Page contents

Summary

Care Identity 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 Care Identity 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 Care Identity 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 the Care Identity 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 for Business    

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 for Business (WHfB). 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 the Care Identity 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. 

Testing

On development environments Care Identity Authentication offers the following additional Authenticator Assurance Level 1 (AAL1) mechanism in the "oidc" realm.

Mechanism Description
Username/Password

This is a standard username and password authentication mechanism where the username is the 12 digit identifier uniquely identifying the End-User within Care Identity Authentication e.g. 999999999999.

This is only offered in the username/password development environments listed in the OpenID Provider Configuration Document URI section.

ACR Values

The ACR values appear in two parts of the authorization code flow, and in the context of Care Identity 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 Care Identity 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
AAL1_USERPASS Setting the acr_values parameter to AAL1_USERPASS in the Authentication Request will result in an AAL1 username and password authentication. This value is only available in the username/password development environments listed in the OpenID Provider Configuration Document URI section.

If the acr_values parameter is not provided in the Authentication Request then a value of AAL3_ANY or AAL1_USERPASS 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. 

 

Additional ACR Values that can be requested

The Care Identity's Authentication support for ACR Values is in development and is currently constrained by the capabilities of the underlying product. As a result Care Identity Authentication only offers partial support for the following additional ACR values:

ACR Value Description
AAL3_IOS Setting the acr_values parameter to AAL3_IOS in the Authentication Request will result in Care Identity Authentication attempting to authenticate the user using the iOS CIS2 Application.
AAL3_FIDO2 Setting the acr_values parameter to AAL3_FIDO2 in the Authentication Request will result in Care Identity Authentication attempting to authenticate the user using FIDO2 via Windows Hello for Business OR Security Key
AAL3_N3_SMARTCARD Setting the acr_values parameter to AAL3_N3_SMARTCARD in the Authentication Request will result in Care Identity Authentication attempting to authenticate the user using a smartcard via the legacy CIS1 Identity Agent.
AAL3_CIS2_SMARTCARD Setting the acr_values parameter to AAL3_CIS2_SMARTCARD in the Authentication Request will result in Care Identity Authentication attempting to authenticate the user using a smartcard via the new CIS2 Identity Agent.
AAL3_SMARTCARD Setting the acr_values parameter to AAL3_SMARTCARD in the Authentication Request will result in Care Identity Authentication attempting to authenticate the user using a smartcard using either of the above smartcard options
AAL2_TOTP Setting the acr_values parameter to AAL2_TOTP in the Authentication Request will result in Care Identity Authentication attempting to authenticate the user using the MS Authenticator TOTP flow, only. 

Use of these ACR Values is subject to the following caveats:

  1. Use of an ACR Value inappropriate for the End-User's device may cause the authentication to fail.
  2. 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.

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

The Care Identity 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 the Care Identity Authentication.
FIDO2 The user was authenticated using FIDO2 via Windows Hello For Business by the Care Identity 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. 
USERPASS The user was authenticated using username and password by the Care Identity Authentication. This value is only returned in the username/password development environments listed in the OpenID Provider Configuration Document URI section.

Last edited: 22 April 2024 10:53 am