Data used by adaptive rules and FIDO policies

Adaptive rules and FIDO policies can examine a large variety of data so they can accommodate a wide range of situations. An Adaptive rule evaluates conditions like the device and its network, a FIDO policy allows specific authenticator groups or characteristics. A post operation check or a supplemental check is performed after the adaptive rule or FIDO policy and it checks risk signals like authenticator key binding and the authenticator’s crypto strength. In addition, you can create your own risk score to use in making authentication decisions.

Context Data: Context data is custom information outside of the Digipass S3 signals and user history that you want to factor into a registration or authentication decision. For example, by using transaction amount and type as context data, you create a condition in an authentication rule that can enforce PSD2 compliance for low-risk, medium-risk, and high-risk transactions. For more information, see Digipass S3 context data.

Conditions

Conditions typically check data supplied by the user's device. Velocity is calculated by the Auth Server.

• App SDK Version: The Digipass S3 App SDK version used by your mobile or web app. You can create rules that use the version number of the App SDK since that may affect the type of data you can use in a rule's condition or approved FIDO authenticators that a user can register.

• Device health: The device's health based on the available jailbreak signal. A signal.

• Device ID: Whether the device ID is known or not. A device ID is known after the device has completed an error-free FIDO authentication on the Digipass S3 Server. Such a device ID is known even if a post operation check in an adaptive authentication rule denied the authentication.

• Device is shared by: The number of users that share the device. This is the same as the “User count on device” signal in a FIDO policy’s post operation or supplemental check.

• Device manufacturer: The manufacturer of the user's device.

• Device model: The model of the user's device.

• Device operating system: The operating system of the user's device.

• Device operating system version: The operating system version of the user's device.

• Device supports platform authenticator: Whether or not the device supports platform authenticators.

• Device type: The type of the user's device.

• IP address: The IP address of the user's device.

• Last Login (time): The user's last login time. User history.

• Last Login Location: The user's geographical location when they last logged in. User history. In a rule condition, last login location can be compared to a list of countries, compared to a list of geofences, or be within a certain distance of the current location.

• Location: The user's current geographic location. In the condition for an adaptive rule, location can be compared to a list of countries, compared to a list of geofences, or within a certain distance of a specified location. If you are implementing a web app and want to use rules based on lists of countries, you must perform additional configuration. See Configure the Google Geocoding Service.

• Operation is transaction: Applies only to authentication rules. Specifies whether or not the user is performing a transaction confirmation. Either "true" or "false".

• Velocity: Only used in Authentication Rules. Calculated from the user's current location, current time, their previous location, and their previous time. Determines whether the user could have reasonably traveled to their current location from their last-logged location.

• WiFi network: The WiFi network the user is connected to. You can restrict the use of your app to specific WiFi networks if your app requires a secure setting.

User History: Data stored in the Server's database. Only used in Authentication Rules.

• Last Login (time): The user's last login time.

• Last Login Location: The user's geographical location when they last logged in.

Table 1: Tells which platforms support a condition you can set in an adaptive rule. The support depends on the protocol used. “All” means the signal is available in Android, iOS and Web App SDKs. “N/A” means not available. See notes following the table.

1. You must configure the App SDK to send this signal. See Configuring Signal Generation in the iOS and Android Developer Guides.

2. To get this signal, you must enable the IP Address plugin on the API Server.

3. Location is sent subject to the end user's consent. You must also configure the App SDK to send the signal. See section Sending the User Location Signal in the Web App SDK Developer Guide or see Configuring Signal Generation in the iOS and Android Developer Guides.

4. Velocity is calculated by the Auth Server based on the current location and the previous location, if available. Velocity is subject to the same requirements as location. Velocity is only available in an authentication operation.

5. WiFi SSD is sent subject to the end user's consent. You must also configure the App SDK to send this signal. See section Configuring Signal Generation in the iOS and Android Developer Guides.

6. The Web App SDK sends the device model if the UA Parser plugin is enabled on the API Server and the user agent string contains the device model. You are more likely to get this information if the web app is running in a mobile browser.

7. On the Web platform, the device type is always browser.

8. The Web App SDK sends the device manufacturer if the User Agent Parser plugin is enabled on the API Server and the user agent string contains the device manufacturer. You are more likely to get this information if the web app is running in a mobile browser.

9. The Web App SDK sends the device operating system and version if the User Agent Parser plugin is enabled on the API Server and the user agent string contains the device operating system and version. You are more likely to get this information if the web app is running in a mobile browser.

10. In OOB, Adaptive Rules are executed using signals from a web app running on a primary device, not the mobile app performing auth that is running on the second device. In version 5.0.0, the Android and iOS App SDKs were enhanced to support OOB in apps on the primary device, although this feature is rarely used.

11. In App-less OOB, Adaptive Rules are executed using signals from a web app running on a primary device, not the browser performing authentication that is running on the second device.

12. Last login is only available in an Adaptive authentication rule.

Risk Signals

Authenticator and device characteristics contain valuable risk signals. Adaptive authentication sequences and FIDO policies both support optional Post Operation checks which assess the degree of threat indicated by a set of risk signals. Post Operation checks are applied by the Auth Server after a user has successfully authenticated with a FIDO method but before the final decision is sent back to the App SDK. A Post Operation Check can either deny authentication or allow it to succeed. A Post Operation Check can also return a risk score to use in making the final decision.

The shared device and multiple device signals utilize a unique and persistent device identifier that is privacy preserving and persists across app uninstalls and reinstalls, but not across factory resets.

Authenticator characteristics depend on knowing the authenticator model. PostOperation Checks or Supplemental Checks that depend on authenticator characteristics listed below must include Attestation Type is full or attca in the condition to ensure the characteristic is valid. The only exception to this is platform authenticator which does not depend on Attestation Type.

• AAGUID, ACKI or AAID: An identifier that uniquely identifies a model of authenticator. For more details, see the FIDO Metadata Statement specification.

  In general, avoid using this in an adaptive rule or FIDO policy because it imposes a burden on you to evaluate and include new identifiers when new devices come out with new authenticators. Instead, specify security characteristics of the acceptable authenticators, such as Key Protection, Key Restricted, Fresh User Verification Required, Matcher Protection, User Presence, User Verification, Authenticator MDS Status, Certification Level, or FIPS 140 Certification Level. If specifying security characteristics is not practical, use Authenticator Groups. For example, make an Authenticator Group containing passkey providers that require step-up authentication when used for the first time on a new platform.

• App integrity: Specifies an application’s integrity. Used for synced passkeys. For Android apps, the Server derives this value from the payload returned by the Google Play Integrity service. The value is in the appRecognitionVerdict field inside appIntegrity. For more information, see Android documentation. For iOS apps, the Server derives this value from the payload returned by the Apple App Attest service. For more information, see Apple documentation. To configure Digipass S3 Authentication Software for this signal, see Support app integrity.

  One of:

  • Is not known

    • Android: payload is invalid or payload is empty or payload contains NOT_APPLICABLE

    • iOS: payload is invalid or payload is empty or payload contains: UNAVAILABLE_ON_CLIENT or UNAVAILABLE_ON_SERVER or NOT_APPLICABLE or SUSPENDED

  • Is acceptable

    • Android: a valid payload contains PLAY_RECOGNIZED

    • iOS: a valid payload is acceptable and contains UNTRUSTED or TRUSTED

  • Is not acceptable

    • Android: a valid payload contains UNRECOGNIZED_VERSION or UNEVALUATED

    • iOS: a payload evaluation is INVALID

• Attestation type: Describes to what degree of certainty the system knows the authenticator model. For more information about attestation type, see the FIDO Registry of Predefined Values. One of:

  • full: Indicates high cryptographic certainty due to full basic attestation, based on an attestation private key shared among a class of authenticators (for example, the same model).

  • attca: Indicates high cryptographic certainty thanks to PrivacyCA attestation. Support for this attestation type is optional at this time.

  • self: There is no certainty in the authenticator model

• Authenticator key binding: Specifies the level of trust provided by the authenticator. The Authenticator key is one of or is not one of:

  • Select all: All types of authenticators are included.

  • Device-bound: The authenticator is as trustworthy as a device-bound passkey, though it is not necessarily a device-bound passkey. The following authenticators are given this designation:

    • A UAF authenticator

    • A device-bound FIDO2 authenticator with known attestation. Such a private key is stored in hardware.

    • A synced passkey with a trusted App Attest credential

  • Syncable: The synced passkey does not have a trusted App Attest credential, so the authenticator is not trustworthy. The following authenticator is given this designation:

    • A synced passkey that was originally registered on a different device, but has not yet been used to authenticate on this device.

  • Uncertain: The Server is not able to determine the authenticator key binding.

  The designation of device-bound passkey is a measure of trust in the key. Ideally, write your Authentication Rules to require that the end user employ additional authentication methods if an authenticator is not as secure as a device-bound passkey. Use a Post Operation Check to bypass those additional authentication methods if the authenticator is as secure as a device-bound passkey.

• Authenticator MDS status: Specifies the status provided by the authenticator. Status are defined by the FIDO Alliance. To learn more about the various status mean as well as an explanation of the possible values, see the FIDO Metadata Service Specification.

  One or more of:

  • Attestation Key Compromise

  • Revoked

  • Self-assertion submitted

  • Update available

  • User key physical compromise

  • User key remote compromise

  • User verification bypass

• Authenticator Metadata: Indicates whether or not metadata is available. Useful for FIDO2 authenticators where metadata may not be present on the Auth Server. One of:

  • Is available: Check for this value in Adaptive Authentication and Registration Decision Rules that use FIDO Auth or FIDO OOB Auth.

  • Is not available: Check for this value only to Adaptive Authentication Rules that use FIDO Auth or FIDO OOB Auth.

• Crypto strength: The authenticator's overall claimed cryptographic strength in bits. This cannot be larger than the strength of the underlying cryptographic algorithm. For more details, see the FIDO Metadata Statement specification.

  A non-negative integer.

• Device Health: Examines the device to see if it has been rooted or the OS was modified. Device health is based on the Jailbreak status which detects if a device has been altered to provide root access. Use this signal to evaluate the risk of malware and the risk of FIDO authentication being circumvented on the device.

• Device ID: A user's device ID is known after the platform has completed an error-free authentication on the Digipass S3 Auth Server.

  • is known

  • is not known

  A unique Device ID is generated by the Digipass S3 App SDK when no existing Device ID can be found on the client platform. Apps can overwrite the Digipass S3 generated Device ID with a custom Device ID, see Custom Device ID.

  Note that in the case of native apps, the device is considered the platform. In the case of web apps, the browser is considered the client platform. Using different browsers on the same device would be considered a different platform and hence will lead to different Device IDs.

  The Device ID can be used in two different places:

  1. Condition for an adaptive rule. When using conditionalUI, the username might not be known yet. In that case, the Device ID is considered "unknown". In the case of out-of-band authentication, the Device ID in the condition of the rule refers to the device that is running the app into which you want to authenticate.

  2. Post Operation check. The username is always known at this stage. Therefore, the Device ID is “known” only if this specific user successfully authenticated with this platform already. In the case of out-of-band authentication, the Device ID in the condition of the Post Operation Check is the device you are using to authenticate into an app running on a different device.

      Device ID is the only signal that can be checked when the Auth server processes a non-FIDO authentication method.

• Device integrity: Specifies the integrity of an Android device. The Server derives this value from the payload returned by the Google Play Integrity service. The value is in the deviceRecognitionVerdict field inside deviceIntegrity. For more information, see Integrity verdicts | Google Play | Android Developers. This value is available for native Android apps only.

  One of:

  • Is not known: payload is invalid or empty

  • Is acceptable: a valid payload contains MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY

  • Is not acceptable: a valid payload contains MEETS_BASIC_INTEGRITY or MEETS_VIRTUAL_INTEGRITY

• Device manufacturer: Specifies the manufacturer of the user's device. For example, "Google" or "Apple".

• Device OS: Specifies the OS of the user’s device. For example, "android" or "iOS" or "Mac OS".

• Device OS version: Specifies the OS Version number of the user's device. For example, "10" or "10.15.7" or "17.1.2".

• FIDO certification level: Specifies the authenticator's FIDO certification level. Certification levels are defined by the FIDO Alliance. To learn more about what the levels mean as well as an explanation of the possible values, see FIDO Authenticator Certification Levels.

• FIPS 140 certification level: Specifies the authenticator's FIPS (Federal Information Processing Standard) 140 certification level.

• Fresh user verification required: Specifies if the authenticator requires a user gesture for each authentication operation, at the time of the operation. For more details, see the FIDO Metadata Statement. Fresh user verification represents a form of “Authentication Intent” as specified in NIST SP 800-63B.

  • true: The authenticator requires some user gesture for user verification, for each authentication at the time of authentication.

  • false: The authenticator doesn't require a fresh user gesture because it may cache the previous gesture for a length of time.

• Friendly Fraud Signal: Utilizes User Verification Set (UVS) to determine if the state of the biometric enrollments on the user’s device have changed. Allows the Server to detect when biometrics are added after a credential is registered.

• Key protection: Specifies how the private key and attestation key are protected. More details can be found in the FIDO Metadata Statement Specification. If you need compliance with the EU Payment Service Directive 2 (PSD2) so that a single authenticator counts as two elements, the authenticator needs to be implemented in a Secure Execution Environment. As a result, key protection must be TEE or secure element. See PSD2 RTS, Article 9 Independence of the elements.

• Key restricted: Indicates if the key can only be used to sign valid FIDO signature assertions (in other words, only FIDO can use the key). For more details, see the FIDO Metadata Statement specification.

  • true: Only FIDO can use the key.

  • false: Other apps can use the key which indicates that the authenticator cannot be trusted. Increases the danger that the key could be compromised

  When key restricted is false, authenticator characteristics such as User Present and User Verification are not reliable.

• Matcher protection: The mechanism used by an authenticator to protect the matcher that performs user verification. More details can be found in the FIDO Metadata Statement specification.

  One of:

  • on chip

  • software (easier to be compromised)

  • TEE

  Guidelines: If you need compliance with the EU Payment Service Directive 2 (PSD2) so that a single authenticator counts as two elements, the authenticator needs to be implemented in a Secure Execution Environment. This might imply a matcher protection value of TEE or on chip. See PSD2 RTS, Article 9 Independence of the elements.

• Platform authenticator: Indicates whether the authenticator is an integral part of a device. This has no direct security impact, but it typically affects the user experience.

  • true: The authenticator is an integral part of a smartphone, tablet, smart watch, or PC.

  • false: The authenticator is a dedicated security device.

• Policy risk score: The total risk score resulting from matching Post Operation Checks in the associated FIDO policy or FIDO OOB policy.

• Registered device count: The number of different devices registered to the user. More devices can increase risk.

• User count on device: The number of users registered on the user’s device. More users can increase risk. This is the same as the “Device is shared by” condition in an adaptive rule.

• User present: Specifies whether the authenticator knows that some user is present and authorizes the operation. For a FIDO2 security key, pressing the button leads to User Present = true, while providing a client PIN doesn’t.

  • true: A user was present and authorized the operation.

  • false: Authorization could have been a machine-approved action.

  A User Verification Method that contains "external" in its name doesn’t count as User Present because the client could have cached the passcode/pattern.

• User verification: Specifies whether the authenticator can verify that the user is authorized to use the authenticator. This value is only reliable when Key Restricted is true. For a FIDO2 security key, providing a client PIN leads to User Verification = true, while pressing the button doesn’t.

  • true: Authentication is considered strong two-factor authentication.

  • false: Authentication is considered strong single-factor authentication.

• User verification method: The methods and capabilities of a UAF authenticator for locally verifying a user. This level of detail is only relevant in rare cases. Without any user verification, a FIDO authenticator provides a strong possession factor. For more details, see the FIDO Registry of Predefined Values. If the User Verification Method is presence internal or none, then authentication provides strong possession-factor authentication. In all other cases, authentication is considered 2FA. All User Verification Methods that include "internal" in their name are fully implemented inside the authenticator. As a result, the client can neither remember nor replay the value. The User Verification Method passcode external (or clientPIN) is supported by many Security Keys. In this case, the passcode is sent to the authenticator and could be cached by the client.

• Custom risk signal: You can create and process a custom risk signal. Contact support@onespan.com for more details.

Table 2: Tells if a specific risk signal is available in a Supplemental check or a Post operation check in an Adaptive rule or a FIDO policy. See notes following the table.

1. In OOB, risk signals are from the mobile app that is performing authentication on the second device, not the web app running on the primary device. In App-less OOB, risk signals come from the browser performing authentication that is running on the second device.

2. You must configure the App SDK to send Device health signal. See Configuring Signal Generation in the iOS and Android Developer Guides. Device health signal is not available when performing App-less OOB. We recommend checking the device health in the condition of an Adaptive rule instead of in the signal of a post operation or a supplemental check.

3. Friendly fraud detection is not applicable for fingerprint authenticators that support automatic key deletion. Friendly fraud detection is not available when performing App-less OOB.

Risk Scores

You can optionally create a risk score to represent the amount of risk imposed by a specific set of risk signals. In this way, you can qualify a decision to allow authentication with a number that tells the amount of risk imposed by that authentication. Use a risk score compiled from a FIDO policy in an adaptive authentication rule’s Post Operation check, or return a risk score to your application server using a dynamic claim. There are two types of risk scores to choose from:

• Auth Sequence risk score: This score results from the successful completion of an authentication sequence. You can use this risk score in the following way:

  • Return it to your application server using a dynamic claim that stores the risk score inside the session token.

• FIDO Auth Policy risk score: When a Post Operation check in a Post operation rule succeeds, the FIDO policy can increment a risk score that starts at 0. You can use this risk score in any of the following ways:

  • Define your FIDO policy to Deny authentication if risk score exceeds a specific threshold.

  • Use it as a risk signal in the Post operation check in an authentication sequence that uses that FIDO policy.

  • Return it to your application server using a dynamic claim that stores the risk score inside the session token.

For more information about Post Operation checks in a FIDO policy, see Step 3. Create FIDO policies. For more information about Post Operation checks in an Adaptive authentication sequence, see Step 5. Create adaptive rulesets. For more information about dynamic claims, see Step 5. Create adaptive rulesets..