Intelligent Adaptive Authentication August Release – 24.R1

The services and endpoints listed below have now been removed from the OneSpan Trusted Identity platform API. For a full list of removed services, see Deprecated or removed components and services.

For every removed service, a replacement is already available in the OneSpan Trusted Identity platform API.

Intelligent Adaptive Authentication no longer supports versions 4.19.3 and 4.20.2 of the Orchestration SDK. The minimum supported SDK version is now 4.21.1.

The documentation for the OneSpan Trusted Identity platform API has been updated for the POST /users/{userID@domain}/login and POST /users/{userID@domain}/events/validate endpoints.

Intelligent Adaptive Authentication now provides the FIDO2 Policy. With this policy you can configure allow and disallow criteria to define which authenticators can be used for FIDO2 registration and authentication operations. Depending on your organization's needs, you can choose between using the default policy or creating a custom policy to perform FIDO2 operations.

The Default policy is automatically applied to all Relying Party resources and is designed to allow all FIDO-certified authenticators. This policy contains one match criterion in the accepted list that matches all FIDO authenticators, and another match criterion in the disallowed list that matches all authenticators that are not FIDO-certified.

The Default policy allows you to configure to allow or disallow self-attestation. Via this configuration option, you control whether the RelyingParty accepts self-signed certificates at registration instead of an attestation certificate that chains back to some root certificate.

If the default policy does not meet your security requirements, you can create a custom policy via the OneSpan Trusted Identity platform API. using the following endpoints.

• Create new FIDO2 policy endpoint. A new FIDO2 policy can be created by calling the following endpoint:

  POST ​/policies

  with the following mandatory request body:

  • name: The name of the policy.

  The responses for this endpoint include the following:

  • 200: Policy created.

    The UUID of the policy will be returned.

  • 400: Input data errors.

  • 500:  Internal error, sub service failure, server crash.

  For more information about how to activate the policy and assign it to a Relying Party resource, see Create and activate a new FIDO2 policy.

• Update existing FIDO2 policy endpoint. An existing FIDO2 policy can be updated by calling the following endpoint:

  PATCH ​/policies/{uuid}

  with the following mandatory parameter:

  • uuid: The unique identifier of the policy.

  The responses for this endpoint include the following:

  • 200: Policy update successful.

  • 400: Input data errors.

  • 404: Policy not found.

  • 500:  Internal error, sub service failure, server crash.

    The default policy cannot be edited, updated, or deleted.

    Only include fields that you want to update.

• Query all FIDO2 policies endpoint. FIDO2 policies can be queried by calling the following endpoint:

  GET ​/policies

  The responses for this endpoint include the following:

  • 200: Policies retrieved successfully.

  • 400: Input data errors.

  • 500:  Internal error, sub service failure, server crash.

• Retrieve a specific FIDO2 policy endpoint. A specific FIDO2 policy can be retrieved by calling the following endpoint:

  GET ​/policies/{uuid}

  with the following mandatory parameter:

  • uuid: The unique identifier of the policy.

  The responses for this endpoint include the following:

  • 200: Policy retrieved successfully.

  • 400: Input data errors.

  • 404: Policy not found.

  • 500:  Internal error, sub service failure, server crash.

• Delete a FIDO2 policy endpoint. A FIDO2 policy can be deleted by calling the following endpoint:

  DELETE ​/policies/{uuid}

  with the following mandatory parameter:

  • uuid: The unique identifier of the policy.

  The responses for this endpoint include the following:

  • 204: Delete operation successful.

  • 400: Input data errors.

  • 404: Policy not found.

  • 500:  Internal error, sub service failure, server crash.

It is not possible to delete the Default Policy.

An active policy cannot be deleted. You must activate another policy to be able to delete the previous active policy.

For more information about the FIDO2 policy, see the following articles:

• FIDO2 policy

• FIDO2-Based Authentication and Registration—FIDO2 (Policy)

• Sample FIDO2 policies

Adaptive authentication and transaction validation processing in OneSpan Intelligent Adaptive Authentication supports challenging an authentication or transaction validation request with OneSpan Risk Analytics.

For the response of this request, Intelligent Adaptive Authentication now also provides information about the Risk Analytics rules that have matched as part of the authentication or transaction validation, via an additional event identifier included in the event lookup. With this identifier and the provided access to this event lookup, you can check all details associated with the event, including the matched Risk Analytics rules.

• Get event ID. A new endpoint has been added for this operation:

  GET ​/events/{eventID}

  The responses include:

  • 200: eventID.

    This response can be one or several of the following values:

    • accountRef

    • beneficiaryBankCountry

    • beneficiaryBank

    • beneficiaryIBAN

    • beneficiaryName

    • customNumber1

    • customNumber2

    • customNumber3

    • customString1

    • customString2

    • customString3

    • customString4

    • customString5

    • customString6

    • uniqueDeviceIdentifier

    • deviceModel

    • authentType

    • authentStatus

    • executionCompleted

    • fingerprintHash

    • fingerprintRaw

    • fraudDate

    • fraudDispositionKey

    • deviceCountry

    • deviceLatitude

    • deviceLongitude

    • clientIP

    • clientIPCountry

    • matchedRules

    • eventDate

    • eventID

    • eventSubTypeKey

    • eventSubType

    • eventTypeKey

    • relationshipRef

    • riskResponseCode

    • sessionID

    • userRef

    You can find a list of these response field values also in the Risk management—event identifiers for matched rules table in Challenges of the Risk Management component where they are identified as non-monetary.

  • 400: The input is invalid.

  • 404: Event ID not found.

  • 500:  Internal error, sub service failure, server crash.

• Get transaction ID. A new endpoint has been added for this operation:

  GET​ /transactions/{transactionID}

  The responses include:

  • 200: transactionID.

    This response can be one or several of the following values:

    • accountRef

    • amount

    • creditorRef

    • creditorBankCountry

    • creditorBank

    • creditorIBAN

    • creditorName

    • currency

    • customNumber1

    • customNumber2

    • customNumber3

    • customString1

    • customString2

    • customString3

    • customString4

    • customString5

    • customString6

    • debtorIBAN

    • debtorName

    • debtorRef

    • uniqueDeviceIdentifier

    • deviceModel

    • authentType

    • authentStatus

    • executionCompleted

    • fingerprintHash

    • fingerprintRaw

    • fraudDate

    • fraudDispositionKey

    • deviceCountry

    • deviceLatitude

    • deviceLongitude

    • clientIP

    • clientIPCountry

    • matchedRules

    • relationshipRef

    • riskResponseCode

    • sessionID

    • transactionDate

    • transactionID

    • transactionSubTypeKey

    • transactionSubType

    • transactionTypeKey

    • userRef

    You can find a list of these response field values also in the Risk management—event identifiers for matched rules table in Challenges of the Risk Management component where they are identified as transaction (i.e., monetary event).

  • 400: The input is invalid.

  • 404: User account not found.

  • 500:  Internal error, sub service failure, server crash.

The following endpoints have been updated to support this feature:

POST /users/{userID@domain}/events/validate

POST /users/{userID@domain}/login

The responses of these endpoints now include the optional eventID field.

POST /users/{userID@domain}/transactions/validate

The response of this endpoint now includes the optional transactionID field.

For more information about this Intelligent Adaptive Authentication feature , see Challenges of the Risk Management component.

OneSpan will launch a new authenticator soon, DIGIPASS FX2. This new authenticator supports multi-device licensing (MDL)-based activation. This MDL license definition slightly differs from that of other MDL authenticators.

To enable the evaluation of DIGIPASS FX2 and the MDL-based activation, a new authenticator type for Intelligent Adaptive Authentication is now available in the Sandbox environment, HWMDL. To evaluate this new authenticator and MDL license type, demo licenses are available when a sandbox tenant is created.

For more information about this and DIGIPASS FX2, please contact our Support team.

The existing restrictions to unlock an authenticator application have been slightly relaxed. Before, Intelligent Adaptive Authentication supported an unlock API but this would only work for authenticator licenses, not authenticator instances. This effectively made it impossible to use multi-device licensing (MDL) hardware authenticators with a built-in unlock functionality.

This has been changed, and it is now possible to also use MDL hardware authenticators that have such an unlock functionality.

In Intelligent Adaptive Authentication, the default configuration of the TID services handling the following flows exhibit bottlenecks:

• Registration

• Provisioning

• Login

• Transactions

• Events

• Orchestration commands

This results in poor performance when many users are simultaneously trying to call the same service.

Status: This issue has been fixed. Performance for users during high-traffic spikes has been improved. A higher number of simultaneous requests can now be handled without performance impairments.

With an overall application improvement, the internal communication between the Intelligent Adaptive Authentication web services has also been improved, resulting in reduced communication and response times.

When a UAF authenticator was deregistered using certain parameters, but no registrations were found, Intelligent Adaptive Authentication incorrectly returned a 409 error message. The relevant parameters or parameter combinations were:

• User name

• User name and AAID

• AAID and key ID

This applied to both FIDO deregistration endpoints:

• POST /users/{userID@domain}/deregister-fido-uaf-keys

• POST /users/{userID@domain}/deregister-fido-uaf-authenticators.

Status: This issue has been fixed. Deregistration is successful, even if no registrations are present. There is one caveat: If a user passes a random string that does not match the AAID format, Intelligent Adaptive Authentication still returns the 409 error message.

This version of Intelligent Adaptive Authentication contains fixes for the following vulnerabilities:

• CVE-2023-1255 (OpenSSL vulnerability)

• CVE-2023-2650 (OpenSSL vulnerability)

• CVE-2023-2975 (OpenSSL vulnerability)

• CVE-2023-3138 (libX11 vulnerability)

• CVE-2023-3316 (libtiff vulnerability)

• CVE-2023-3446 (OpenSSL vulnerability)

• CVE-2023-3817 (OpenSSL vulnerability)

• CVE-2023-4863 (libwebp vulnerability)

• CVE-2023-5678 (OpenSSL vulnerability)

• CVE-2023-6129 (OpenSSL vulnerability)

• CVE-2023-6237 (OpenSSL vulnerability)

• CVE-2023-29491 (ncurses vulnerability)

• CVE-2023-35945 (HTTP/2 vulnerability)

• CVE-2023-38039 (cURL vulnerability)

• CVE-2023-38545 (cURL vulnerability)

• CVE-2023-38546 (libcurl vulnerability)

• CVE-2023-44487 (HTTP/2 vulnerability)

• CVE-2023-46218 (curl vulnerability)

• CVE-2023-46219 (curl vulnerability)

• CVE-2023-47038 (Perl vulnerability)

• CVE-2024-0727 (OpenSSL vulnerability)

For the POST /users/{userID@domain}/transactions/validate endpoint, the description of the TransactionValidationInput and AdaptiveTransactionValidationInput schema fields Title and Subject were not clear enough and did not explain that the title and subject fields are used to display the Push Notification message in the notification drop-down menu on the mobile device.

Status: This issue has been fixed. The description now explains that title and subject are only used when the orchestrationDelivery field is set to pushNotification, and are not used when requestMessage is selected.

In the Interactive API Reference, we provide payloads that serve as examples for how to implement our endpoints. Some of these endpoints contain the fingerprintRaw element in their payload. The sample payloads used an incorrect value for this element. This applied to the following endpoints:

• POST /events

• POST /users/{userID@domain}/events/validate

• POST /transactions

• POST /users/{userID@domain}/transactions/validate

• POST /users/{userID@domain}/login

• POST /users/register

• POST /users/{userID@domain}/unregister

Status: This issue has been fixed. These endpoints now have the correct sample payload.

The POST /users/{userID@domain}/transactions/validate endpoint returns an incorrect error message if the transaction amount field is provided from the data type number, and if the transaction amount is large. In this case, the endpoint should return the error message "Invalid value type", because the transaction amount field was provided as a number and not as a String. Instead, it returns the incorrect error message "Amount: Value must follow -^-?[0-9]{1,20}(\\.[0-9]{1,3})?$,".

Solution: The transaction amount fields in the request body of the transactions/validate endpoint need to be provided as a String. Ensure that the value in the JSON request body is wrapped in double quotes.

Intelligent Adaptive Authentication supports the following versions of the Orchestration SDK Client:

• 5.9.0

• 5.8.1

• 5.8.0

• 5.7.0

• 5.6.4

• 5.6.3

• 5.6.0

• 5.5.1

• 5.4.4

• 5.4.2

• 5.4.0

• 5.3.1

• 5.3.0

• 5.2.0

• 5.0.2

• 4.24.4

• 4.24.2

• 4.23.0

• 4.21.1