Introduction
Digipass S3 Adaptive Rulesets implement intelligent decision-making in your mobile and web apps. Rulesets control the authentication methods that a user can register and, more importantly, customize how the user is verified based on contextual information. Rulesets contain both Registration and Authentication Rules. These rules embody the criteria and guidelines from your organization by evaluating data provided by your app and a small set of user history.
Using these rules, the Auth Server renders a decision. For registration, a decision can be:
Deny: The user isn't given the option to register.
Suggest Registration: The user can register one or more authentication methods. They can defer registration or cancel out of it.
Enforce Registration: The user registers one or more required authentication methods. They cannot use the app for other tasks until they have registered those methods.
Ignore Registration: Registration is not possible. This is not an error condition.
For authentication, a decision can be:
Deny: The user's authentication request is denied
Allow: The user is immediately authenticated without any further action
Trigger authentication: The user must verify their identity using one of the authentication sequences returned with this decision.
An example list of sequences is shown below. A sequence can require that the user register or authenticate with several methods, as shown in the last bullet point.
FIDO authentication
FIDO2 security key authentication
SMS OTP and Email OTP and Photo ID authentication
Sequences can contain FIDO and FIDO OOB as well as OTP and Photo ID. This Digipass S3 documentation refers to FIDO authentication, FIDO OOB, Email OTP, SMS OTP and Photo ID collectively as authentication methods.
You can exert additional control over the registration and authentication process after the user registers or authenticates. Some authenticator and device characteristics are only known after the authenticator has been used. This is especially true for FIDO2 authenticators. For example, device integrity is linked to the authenticator but it is only known after authentication. A Post operation check in an authentication rule can examine both the device OS and device integrity. See Data used by Adaptive rules and FIDO policies for a list of all the risk signals you can check in a Post operation rule.
Ideally, you want to confirm that the authenticator upholds your organization's standards. You may also have a requirement that the end user has previously used the same device, either during registration or a previous authentication operation. If the authenticator is substandard, you want to encourage the user to register additional authentication methods or require that they authenticate with additional methods.
A PostOperation Check or a Supplemental Check compares the characteristics of the authenticators and device to your organization's guidelines for those properties. If the comparison is true, the Authentication Server performs an action instead of continuing to process the remaining methods in the sequence.
For registration, a Supplemental Check detects if the FIDO authenticator is strong. If it is, registration is determined to be complete because no other authentication methods need to be registered.
For authentication, a PostOperation Check's action is one of:
Allow: Authentication is complete because the authenticator is strong
Deny: Authentication fails because the authenticator is weak
Drop sequence: Authentication with the current authentication sequence fails because the authenticator is substandard. The Authentication Server switches authentication to use methods from an alternate sequence, if one is available from the succeeding Authentication Rule.
Note that when the action is Drop Sequence the Server gives the user a chance to authenticate with a different method.