May Release – 22.R2

The FIDO2 Sample Relying Party Web App is a stand-alone component hosted in the Sandbox environment. It facilitates the testing and simulation of the end-to-end capabilities of the FIDO2 ceremonies.

Once FIDO2 has been enabled, you can access the FIDO2 Sample Relying Party Web App via https://yourtenant.sdb.tid.onespan.cloud/v1/fido-sample-relying-party.

For more information about the FIDO2 Sample Relying Party Web App, see FIDO2 Sample Relying Party Web App.

For more information on the FIDO2 Sample Relying Party Web App interaction with the web browser and the OneSpan Trusted Identity platform API, see Using the FIDO2 Sample Relying Party Web App to test the registration and deregistration flow and Using the FIDO2 Sample Relying Party Web App to test the authentication flow. The code samples demonstrate how to use the WebAuthn API for the registration, deregistration, and authentication flows.

For more information on FIDO2 onboarding for the Sandbox environment, see FIDO2 onboarding in the Sandbox environment.

The FIDO2 onboarding process is now available on the OneSpan Community Portal for OneSpan Cloud Authentication.

For more information on FIDO2 onboarding for the Sandbox environment, see FIDO2 onboarding in the Sandbox environment.

For more information on FIDO2 onboarding for the Production environment, see FIDO2 onboarding in the Production environment.

Event listeners have been implemented in certain TID microservices to listen to the key expiration events of specific keys. After a Redis key expiration event is received, the related key is properly deleted.

The following TID microservices are impacted:

• checksessionstatusv2 (RequestStatus)

• authenticator-provisioningv2 (registrationsession)

• sandbox (sandbox-tenantdeletestatus, sandbox-tenantstatus)

• eventvalidationv2 (SessionRequestMapping)

• irm_macroservices_trusteddevicecmd (SessionStatus)

• oas-admin-pool (TenantAdminSession)

• checkactivationstatusv2 (CacheElement)

When finalizing the registration process, the FIDO2 Server now validates if the attestation mode (aka Attestation Conveyance Preference) is compatible with the attestation statement that the authenticator sends. If the attestation statement is empty, the attestation mode must be NONE. It is not compatible if the attestation statement is empty and the attestation mode is set to DIRECT or INDIRECT.

OneSpan Cloud Authentication now supports the emailAddress field for the following OneSpan Trusted Identity platform API endpoint:

• GET /users

You can now query a user based on the emailAddress field in OneSpan Cloud Authentication.

OneSpan Cloud Authentication now supports the displayName field for the following OneSpan Trusted Identity platform API endpoints:

• GET /users

• PATCH /users/{userID@domain}

You can now query a user or update user data based on the displayName field in OneSpan Cloud Authentication.

The default timeout value for Secure Channel-based authentication and transaction data signing operations has been increased from 60 seconds to 180 seconds.

Contact OneSpan Support if you need to change this configuration.

A new FIDO endpoint has been added to the OneSpan Trusted Identity platform API to retrieve a trusted facets list for FIDO UAF certification. This is a list of all the approved entities related to the calling app.

GET ​/fido-uaf-app-facets

The following failure responses are included:

• 500: Unexpected server error.

OneSpan Cloud Authentication now supports online multi-device licensing (MDL) provisioning to activate an authenticator. This functionality was available only for integrations of OneSpan Cloud Authentication that also included the OneSpan Orchestration SDK in the mobile application. With this new feature, the required DSAPP-SRP operations are now available through the OneSpan Trusted Identity platform API. During the activation process, an authenticator instance is created.

For this type of activation, an authenticator license is required.

• Ephemeral key endpoint. A new endpoint has been added to generate an ephemeral key and secure the activation process:

  POST /registrations/{registrationID}/generate-ephemeral-key

  This endpoint accepts clientEphemeralPublicKey as payload.

  The following failure responses are included:

  • 400: The input is invalid.

  • 404: The registration session was not found.

  • 409: Incorrect activation type.

  • 500: Unexpected server error.

• Generate activation message endpoint. A new endpoint has been added to generate the activation message:

  POST /registrations/{registrationID}/generate-activation-message

  This endpoint accepts clientEvidenceMessage as payload.

  The following failure responses are included:

  • 400: The input is invalid.

  • 404: The registration session was not found.

  • 409: Incorrect activation type or authenticator does not support activation.

  • 500: Unexpected server error.

• Update PNID endpoint. A new endpoint has been added to update the Push Notification Identifier (PNID):

  POST /users/{userID@domain}/authenticators/{serialNumber}/update-pnid

  This endpoint accepts encryptedMessage as payload.

  The following failure responses are included:

  • 400: The input is invalid.

  • 404: The user account or authenticator was not found.

  • 409: Failed to update the PNID for the authenticator.

  • 500: Unexpected server error.

For more information, refer to Integrate provisioning for multi-device licensing (MDL).

The offline provisioning of multi-device licensing (MDL) authenticators has been improved. Because the device code input has become optional when initiating a registration session, two separate workflows are now available.

The following endpoint has been extended:

POST /registrations

Accepted payload if the device code is present:

• registrationID, with the following field:

  • deviceCode

Accepted payload if the device code is not present:

• registrationID

For more information, refer to Integrate provisioning for multi-device licensing (MDL).

A new tool for investigating the performance of OneSpan Cloud Authentication has been introduced. Until now, the investigation of any performance issues was based on logs. With the integration of a new performance analysis instrument, OpenTelemetry, it is now possible to provide a standardized method to handle traces for microservices. The availability of performance output for analysis reduces the time to find core performance issues, as well as operation costs, and the time required to fix performance-related issues.

The POST /users/{userID@domain}/deregister-fido-uaf-keys and the POST /users/{userID@domain}/deregister-fido-uaf-authenticators endpoints do not support audit logging.

Status: This issue has been fixed.

The POST /authenticators/{serialNumber}/applications/{applName}/test endpoint supports two types of input data:

• otp, with response and hostCode as expected payload

• signature, with response and eight data fields (data1 ... data8) as expected payload

No issues occur if a Response-Only (RO) application is provided for the OTP flow, or a signature (SG) application for the signature flow. However, if a Challenge/Response (CR) application is provided for an OTP flow, OneSpan Cloud Authentication returns the STAT_CHALLENGEstatus code, which is mapped to ERROR.

Status: This issue has been fixed.

The default level for log entries that are created by the Transactionv3 web service is DEBUG. On the staging and production environments of OneSpan Cloud Authentication, however, the default log level is INFO. Because of this, there is no log information available on the Transactionv3 service.

Status: This issue has been fixed.

The FIDO Server returns FIDO UAF status code mismatches when the FIDO Conformance Tools are run against the FIDO registration endpoints in the OneSpan Trusted Identity platform API.

Status: This issue has been fixed. The UAF status codes have been corrected in the OneSpan Trusted Identity platform API. For more information about UAF status codes, refer to the FIDO Alliance documentation.

The FIDO Server returns FIDO UAF status code mismatches when the FIDO Conformance Tools are run against the FIDO authentication endpoints in the OneSpan Trusted Identity platform API.

Status: This issue has been fixed. The UAF status codes have been corrected in the OneSpan Trusted Identity platform API. For more information about UAF status codes, refer to the FIDO Alliance documentation.

The OneSpan Cloud Authentication admin pool expects a SOAP URL entry for sessions. After an update of the Production environment, the old sessions are still alive but are missing the SOAP URL. If that URL is not present, the service does not fall back to anything, which results in a service outage.

Status: This issue has been fixed. OneSpan Cloud Authentication now creates new sessions that include the SOAP URL.

For the user register microservice, OneSpan Cloud Authentication logs important messages incorrectly on lower log levels. In addition, the payload is logged incorrectly as a string value.

Status: This issue has been fixed. The log levels in the relevant microservice have been corrected, and the payload is now correctly formatted.

The Audit Logger service does not report all errors correctly. In some cases, a request is marked as success, and the microservice is not notified that an error occurred.

Status: This issue has been fixed. In case of failure, the microservice is notified that the request has failed, and an AuditLoggerClientException error is returned.

When configuring FIDO UAF for a tenant, a Relying Party entity has to be created via the FIDO UAF Policy Manager Service. The two fields tlsServerCertificateEndPoint and tlsServerCertificateHashEndPoint, which are part of the Relying Party entity, are mandatory fields. The Relying Party cannot be created if these two fields are null or empty. A possible workaround is to set dummy values for these two fields in case the Boolean fields tlsServerCertificateSupported and serverEndPointSupported are set to false.

Status: This issue has been fixed. Both fields can be null or empty if the Boolean fields are set to false. They need to be set only if the Boolean fields are set to true. With this, the tlsServerCertificateEndPoint and tlsServerCertificateHashEndPoint fields are no longer mandatory.

For general information about FIDO-based operations, refer to FIDO-Based Authentication and FIDO-Based Transaction Data Signing.

For information about integrating FIDO-based operations, refer to the following articles:

• Integrating user login with -based authentication, and

• Integrating FIDO-based transaction data signing.

In the endpoint to set up the Relying Party for FIDO2, the publicKeyCredentialDescriptors element is mandatory in the request body. At this stage of creating the Relying Party, however, there are no registrations and thus no credential IDs that could be supplied in the request body. Thus, the mandatory nature of this element is incorrect.

Status: This issue has been fixed. It is now possible to set the publicKeyCredentialDescriptors to null or empty, or to not include it at all in the request body.

For general information about FIDO-based operations, refer to FIDO-based authentication and FIDO-based transaction data signing.

For information about integrating FIDO-based operations, refer to the following articles:

• Integrating user login with -based authentication

• Integrating FIDO-based transaction data signing

The fido2-core library uses Log4J as an external dependency. This library contains the following critical vulnerabilities:

• CVE-2021-44228

• CVE-2021-45046

• CVE-2021-45105

Status: This issue has been fixed. The fido2-core library has been updated to use Log4j version 2.17, which fixes these vulnerabilities.

The following microservices have a dependency on the fido2-core library:

• fido2-service

• fido2-config-manager

• fido-universal-server (uses the API from fido2-service)

For the following SOAP commands in the Orchestration Messaging microservice, the tenant name is incorrectly used as a domain parameter:

• DecryptInformationMessageCommand

• EncryptRequestMessageCommand

The issue has been present in the services that served as the basis for, and were replaced by the Orchestration Messaging microservice.

Status: This issue has been fixed. The correct domain is now used in the relevant microservices, and misleading logs are removed.

The FIDO2 authenticator registration fails if the attestation mode NONE is used in the request to initialize the registration when calling the POST /users/{userID@domain}/generate-fido-registration-request endpoint.

Status: This issue has been fixed.

When a user attempts to activate a multi-device licensing (MDL) compatible device after a static password has expired, the POST /registrations endpoint returns the status code error 500 with a generic error message. In this case, however, the endpoint should return status code error 409, with the error message Static password has expired.

Status: This issue has been fixed.

OneSpan Cloud Authentication supports the following versions of the Orchestration SDK Client:

• 5.5.1

• 5.4.4

• 5.4.2

• 5.4.1

• 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

• 4.20.2

• 4.19.3