Design guidelines
The Authentication Server performs Adaptive Registration when you use the recommended App SDK methods, documented in the App SDK Developer Guides, to suggest a FIDO authenticator to register during Sign-in, or to register an OTP method or Photo ID. Otherwise, FIDO registration uses your designated FIDO registration policy.
The Authentication Server performs Adaptive Authentication when you use the recommended App SDK methods to authenticate. The implementation described in the App SDK Developer Guides preferentially uses FIDO authentication over other authentication methods.
When you design your Adaptive Rules, the conditions should cover the space of all possibilities. You need to create and examine rules that are permutations of all the ways you can combine your data. Avoid creating rules such that 2 or more rules succeed given the right circumstances If there are alternate ways to authenticate, represent these as different sequences in the same rule.
The order of your rules within a ruleset is significant and impacts your rule's conditions. The Authentication Server takes a ruleset and executes each rule sequentially, starting with the first one. Consequently, you can think of rule order as emulating an if-then-else statement. Place rules that deny registration or authentication at the top of a ruleset. Later rules do not need to test for conditions present in earlier rules because they have already been filtered out.
Sequences can be different between Registration and Authentication Rules. During registration, ensure that the user has all the authenticators that they need to successfully authenticate. During authentication, the sequence should contain the appropriate secure authenticators for the specific situation.
Your rule's authentication and registration sequences should contain all the necessary authentication methods to ensure secure authentication in case your FIDO authenticator is weak. For example, your organization's guidelines are that customers can successfully authenticate using one strong biometric FIDO authenticator that stores its key in hardware. However, if the customer only has a weak FIDO authenticator that stores its key in software, your company wants that customer to use either SMS OTP or email OTP for added security. For this example, define a rule with two sequences. One sequence contains FIDO authentication and SMS OTP while the other contains FIDO authentication and email OTP.
If you create a sequence that includes a FIDO authenticator and other methods, place the FIDO authenticator first in that sequence.
Your organization's criteria and guidelines for secure authentication are enforced by FIDO policies, PostOperation Checks in an authentication rule and Supplemental Checks in a registration decision rule. A FIDO policy restricts the allowed FIDO authenticators before a user registers or authenticates. A PostOperation Check or a Supplemental Check validates that the authenticator and/or device complies after the user has registered a FIDO authenticator or used it to verify their identity.
FIDO policies enforce your organization's choice of valid FIDO authenticators when a user registers and authenticates. For UAF, this is a list of AAIDs. For FIDO2, you specify the values you want for 6 key characteristics: public key credential hints, discoverable credential, user verification, attestation preference, and cross origin operations.
Not all FIDO authenticators are created equal. Depending on your organization's criteria, some authenticators clearly meet your standards while others are not secure or are otherwise undesirable, perhaps due to cost or because they aren't likely to be used by customers (such as security keys). Create your FIDO policies to reflect this and make sure the set of acceptable authenticators used to verify users is equal to or a subset of what users can register.
When you create a Registration or Authentication Rule, you designate the acceptable FIDO authenticators in its sequence with a specific FIDO policy. For example, you could have one FIDO policy that only allows platform authenticators while another one allows security keys.
Use a PostOperation Check in an authentication rule to ensure the authenticator used conforms to your organization's standards. You can only define a PostOperation Check if there is another authentication method following.
During Adaptive Registration, a Supplemental Check functions like a break statement in your sequence. The Supplemental Check embodies your organization's definition of a strong FIDO authenticator. Remember that a sequence contains all required authentication methods in case you have a weak FIDO authenticator. If you have a strong FIDO authenticator, those additional methods are unnecessary. When a Supplemental Check succeeds (its condition evaluates to true), the Server concludes that registration is complete because the user registered a strong FIDO authenticator. This decision is sent to the Digipass S3 App SDK, so the App SDK does not prompt the end user to register the remaining authentication methods.
During Adaptive Authentication, when a PostOperation Check succeeds, it also functions like a break statement but with three potential outcomes. Authentication could be complete because the FIDO authenticator was strong, authentication could fail because the FIDO authenticator was weak, or the FIDO authenticator lacks the characteristics that would work with the remaining authentication methods. For that last situation, the Server terminates the current sequence and attempts to finish authentication with a different sequence from the succeeding Authentication Rule.
Design example
Company X, a financial services organization, wants all their customers to register and authenticate with FIDO authentication, if possible. Company X's customers fall into four categories:
Customers with modern smartphones and devices: These customers should register and use a FIDO platform authenticator.
Customers with older phones or with phones without reliable biometric authentication. For example, these are phones that are on an exclusion list provided by a regional banking regulatory authority: These customers should register and use the authenticator available on their phone as well as either email OTP or SMS OTP.
Customers with mobile devices who use Company X's web app on their PCs: These customers should use either a security key or FIDO OOB so they can authenticate to the web app using their mobile device.
Customers without mobile devices who use Company X's web app on their PCs: These PCs don't have FIDO2 platform authenticators and the users aren't likely to have security keys. Company X wants these users to use both SMS OTP and email OTP.
Company X has noted an increase in fraudulent activity originating in certain countries. It does not want its customers to use their app in those countries.
Policies
Create the following FIDO policies.
FIDO Policy #1: UAF authenticators and FIDO2 Platform
UAF Authenticator groups:
Android/iOS Lock Screen - Hardware
Android/iOS PIN - Hardware
Android/iOS Presence - Hardware
Android/iOS Silent - Hardware
Android/iOS Strong Biometric - Hardware
Android/iOS Any Biometric - Hardware
FIDO2 Platform only
Public Key Credential Hints: Client Device
User Verification: Required
Reject if user wasn't verified checkbox: Checked
FIDO Policy #2: UAF Authenticators and Security Keys
UAF Authenticator groups:
Android/iOS Lock Screen - Hardware
Android/iOS PIN - Hardware
Android/iOS Presence - Hardware
Android/iOS Silent - Hardware
Android/iOS Strong Biometric - Hardware
Android/iOS Any Biometric - Hardware
FIDO2 Security Keys only
Public Key Credential Hints: Security Key
User Verification: Required
Reject if user wasn't verified checkbox: Checked
Registration decision rules
IF the user's location is not in an allowed country,
THEN Deny
IF the device supports platform authenticators,
THEN Suggest Authentication
Sequences:
(FIDO auth using Policy #1, SMS OTP)
Supplemental Check (using characteristics for NIST 800-63 AAL3 compliance)
IF Attestation Type is one of (full, attca) and
Key Protection is one of (TEE, secure element) and
Key Restricted is true and
Matcher Protection is one of (TEE, on chip) and
User Verification is true and
Certification Level is not one of (User Verification Bypass, User Key Remote Compromise, Revoked, Attestation Key Compromise)THEN Done
(FIDO auth using Policy #1, email OTP)
Supplemental Check (using characteristics for NIST 800-63 AAL3 compliance)
IF Attestation Type is one of (full, attca) and
Key Protection is one of (TEE, secure element) and
Key Restricted is true and
Matcher Protection is one of (TEE, on chip) and
User Verification is true and
Certification Level is not one of (User Verification Bypass, User Key Remote Compromise, Revoked, Attestation Key Compromise)THEN Done
IF the device doesn't support platform authenticators,
THEN Suggest registration
Sequences:
FIDO OOB auth using Policy #2 (Security key, UAF authenticators) and SMS OTP
Use same Supplemental Check as above
FIDO OOB auth using Policy #2 (Security key, UAF authenticators) and email OTP
Use same Supplemental Check as above
FIDO auth using Policy #2 (Security key, UAF authenticators)
SMS OTP and email OTP
IF the device doesn't support platform authentication
THEN ignore registration
Authentication rules
IF the user's location is not in an allowed country
THEN Deny
IF last login > 60 minutes and no activity in 10 minutes
THEN Trigger Authentication
Sequences:
(FIDO auth using Policy #1, SMS OTP)
PostOperation Check (using characteristics for NIST 800-63 AAL3 compliance)
IF Attestation Type is one of (full, attca) and
Key Protection is one of (TEE, secure element) and
Key Restricted is true and
Matcher Protection is one of (TEE, on chip) and
User Verification is true and
Certification Level is not one of (User Verification Bypass, User Key Remote Compromise, Revoked, Attestation Key Compromise)THEN Done
(FIDO auth using Policy #1, email OTP)
PostOperation Check (using characteristics for NIST 800-63 AAL3 compliance)
IF Attestation Type is one of (full, attca) and
Key Protection is one of (TEE, secure element) and
Key Restricted is true and
Matcher Protection is one of (TEE, on chip) and
User Verification is true and
Certification Level is not one of (User Verification Bypass, User Key Remote Compromise, Revoked, Attestation Key Compromise)THEN Done
FIDO OOB auth using Policy #2 (Security key, UAF authenticators) and SMS OTP
Use same PostOperation Check as above
FIDO OOB auth using Policy #2 (Security key, UAF authenticators) and Email OTP
Use same PostOperation Check as above
FIDO auth using Policy #2 (Security key, UAF authenticators)
SMS OTP and Email OTP
IF transaction type is one of (balance, summary, history)
THEN Allow
IF the transaction type is one of (purchase-stock, transfer, wire, sell-stock) AND
transaction amount < 100
THEN Allow (The user has already logged in and this is a low value transaction so don't ask them to authenticate again)
IF the transaction type is one of (purchase-stock, transfer, wire, sell-stock) AND
transaction amount >= 100
THEN Trigger Authentication (For high value transactions, ask the user to authenticate again)
Sequences:
(FIDO auth using Policy #1, SMS OTP)
PostOperation Check (using characteristics for NIST 800-63 AAL3 compliance)
IF Attestation Type is one of (full, attca) and
Key Protection is one of (TEE, secure element) and
Key Restricted is true and
Matcher Protection is one of (TEE, on chip) and
User Verification is true and
Certification Level is not one of (User Verification Bypass, User Key Remote Compromise, Revoked, Attestation Key Compromise)THEN Done
(FIDO auth using Policy #1, email OTP)
PostOperation Check (using characteristics for NIST 800-63 AAL3 compliance)
IF Attestation Type is one of (full, attca) and
Key Protection is one of (TEE, secure element) and
Key Restricted is true and
Matcher Protection is one of (TEE, on chip) and
User Verification is true and
Certification Level is not one of (User Verification Bypass, User Key Remote Compromise, Revoked, Attestation Key Compromise)THEN Done
FIDO OOB auth using Policy #2 (Security key, UAF authenticators) and SMS OTP
Use same PostOperation Check as above
FIDO OOB auth using Policy #2 (Security key, UAF authenticators) and Email OTP
Use same PostOperation Check as above
FIDO auth using Policy #2 (Security key, UAF authenticators)
IF TRUE
THEN Trigger Authentication
Sequences:
(FIDO auth using Policy #1, SMS OTP)
PostOperation Check (using characteristics for NIST 800-63 AAL3 compliance)
IF Attestation Type is one of (full, attca) and
Key Protection is one of (TEE, secure element) and
Key Restricted is true and
Matcher Protection is one of (TEE, on chip) and
User Verification is true and
Certification Level is not one of (User Verification Bypass, User Key Remote Compromise, Revoked, Attestation Key Compromise)THEN Done
(FIDO auth using Policy #1, email OTP)
PostOperation Check (using characteristics for NIST 800-63 AAL3 compliance)
IF Attestation Type is one of (full, attca) and
Key Protection is one of (TEE, secure element) and
Key Restricted is true and
Matcher Protection is one of (TEE, on chip) and
User Verification is true and
Certification Level is not one of (User Verification Bypass, User Key Remote Compromise, Revoked, Attestation Key Compromise)THEN Done
FIDO OOB auth using Policy #2 (Security key, UAF authenticators) and SMS OTP
Use same PostOperation Check as above
FIDO OOB auth using Policy #2 (Security key, UAF authenticators) and Email OTP
Use same PostOperation Check as above
FIDO auth using Policy #2 (Security key, UAF authenticators)
SMS OTP and Email OTP