Fields used in the Authentication Journey

An authentication policy is a template containing predefined parameters enforced during authentication, such as password lengths or constraints, OTP synchronization protocols, and push notification signature details etc.

Choose an existing authentication policy from the drop-down list.

For example: User Static Password, Standard One Time Password, HID Approve Push Authentication, and FIDO Token etc.

Maximum number of times the user can attempt to authenticate before the login session is restarted.

For example: 1, 2, 3, and 4 etc.

The validity period of the authenticator.

Enter the threshold value (in seconds) to display a warning message for authenticator expiration.

For example: 36000 seconds

The ACR value defines the level of assurance Level of Assurance is the level of confidence in the claimed identity of a user during authentication. provided by the authentication process to the user's claim to the 'identity' they use to authenticate.

It specifies the conditions required by a provider or relying party that define how a user authenticates to mitigate specific authentication risks.

For example, if you define the same authentication method as both a first and second authentication factor, you can set a higher level of assurance (i.e, the value can be 1, 2, and 3 etc) when it is used as a second authentication factor.

Choose the first factor required to authenticate from the Trigger on drop-down list so that the second factor occurs.

The Trigger on drop-down displays the list of authentication factors that were configured from the first step. It supports for both single selection and multi-selection of authentication factors.

For example:

In the first step, you have configured "Static Password" and "Push Authentication". In the second step, consider you want "One-Time Password" as the authentication method.

You can use Trigger on drop-down to apply a criteria for One-Time Password authentication, where in One-Time Password can be accessed only through Static Password or/and Push Authentication.

Define if the user is required to verify their physical presence (such as providing the PIN, biometric credential or touching the FIDO authenticator).

Possible values are:

• Discouraged

• Preferred

• Required

The hostname of your application that is integrated with HID.

For example: myapp.example.com

The user can assign their physical device to the authenticator.

Defines if the user must have a "pending" device of the specified device type to be able to enroll their device.

Possible values are:

• Required

• Not Required

If you set this to "Required", you must create and assign a FIDO authenticator for the user before they can enroll their device.

If absent or undefined, the value is considered to be "Not Required".

Defines if a cryptographic key, which is stored on the security key, can be used for passwordless login.

Possible values are:

• Discouraged - a non-resident key is preferred (that is, the user information and credential ID is stored on the server) but HID Authentication Service will accept a resident key

• Preferred - the resident key is preferred (that is, the user information and credential ID is stored on the FIDO authenticator) but HID Authentication Service will accept a non-resident key

• Required - the resident key is required

If the request is denied by the FIDO authenticator, enrollment will fail.

Defines if the user's FIDO authenticator is required to provide an attestation The attestation is a key pair specific to a device model and can be used to cryptographically prove that a user has a specific model of device when they register. statement for verification at enrollment.

Possible values are:

• Direct - the attestation statement should be generated by the device

• None - the attestation statement is not required

Defines if the enrollment should be validated by a successful authentication using the newly enrolled authenticator.

Defines the protection factor applied for the enrollment action.