Feature: Enable ability to populate ID token acr claim value to support TDIF and possibly NIST + other standards

Feature: This feature will enable the modification of the acr claim value in ID tokens (via actions/rules et al), so that Auth0 can support specific acr claim values relating to TDIF and NIST identity assurance.

Presently, it is not possible to specify the value of the ID token’s acr claim.

Description: The TDIF specification requires a specific set of values for the ID token’s acr claim depending on the identity assurance level and credential level met by the end-user at the time of authentication. (spec can be found here: https://www.digitalidentity.gov.au/sites/default/files/2021-02/tdif-06b-openid-connect-1.0-profile-release04-v1.0.pdf (see pages 25-29 and 48-50). The language in the specification refers specifically to acr claim and requirement as must have. Therefore namespaced claims do not meet the requirements of the standards.

Note: Identity assurance is defined by the National institute of standards (NIST) from the U.S. department of commerce, and also defined in the the Trusted digital identity framework (TDIF) from the Australian digital transformation agency (which is strongly aligned to the NIST standard).

Use-case: Relying parties (RP) may request acr_values in the format (below). At the time of user authentication, Auth0 will derive a value which matches the request, or as close to the request as possible in the same format as possible.

acr format: urn:id.gov.au:tdif:acr:IPn:CLn

The result is a value containing a identity proofing level value (IPn) and a credential level value (CLn) which are combined in the above format, the result is then set as the acr claim value in the ID token. As the TDIF standard defines the acr claim as being a must have, a namespaced claim can not be used. i.e. the value must be contained in the acr claim

The IPn is a value derived from identity proofing information provided by the end-user and verified in an external process prior to authentication. How the IPn value is stored or derived is outside of the context of this feature as there are already suitable mechanisms for this. i.e. The value may be stored in app_metadata, or externally and retrieved by API call.

The CLn is a value which reflects the level of authentication in terms of additional factors used. e.g. cl1: email + password, cl2: email +password + MFA, cl3: email + password + MFA + biometrics

For more detail, please see: https://www.digitalidentity.gov.au/sites/default/files/2021-02/tdif-06b-openid-connect-1.0-profile-release04-v1.0.pdf for details.

Hi @aaronctmr,

Thank you for your valuable feedback. Let’s hope this feature attracts many votes!

Please don’t forget to vote for this request!

Have a great rest of your day.