Out-of-Band Transaction Confirmation

Description

Out-of-band transaction confirmation allows users to authorize transactions on their mobile phones. Transactions can consist of simple text messages or images that a user can confirm with his mobile authentication credentials. This is useful for any kind of operation where trusted, verified user consent is required - for example credit card or bank transactions.

info

Note that the channel linking mechanism and the Out-Of-Band mechanisms described in the Out-of-Band Authentication chapter also apply to the out-of-band transaction confirmation.

info

The difference between the in-band and the out-of-band transaction confirmation processes lies in the push message related parts: In case of in-band transaction confirmation, the relying party mobile client application can directly request a transaction confirmation authentication request from the Nevis backend.

Prerequisites

• The user must have two devices at hand. One device is a laptop or desktop computer. The other is a mobile device, where the user signs the transaction.
• A mobile application is installed on the mobile device. This mobile application must either use the Nevis Mobile Authentication SDK (which provides functionality for the use case) or be able to deal with the FIDO UAF protocol as well as push notifications.
• The user has previously registered FIDO Authenticator credentials on his mobile device. Registration can be done via In-Band Registration or Out-of-Band Registration.

Different scenarios

Transaction confirmation scenarios differ in two ways. The user may not notice these differences, but they are significant from an integration point of view. The main difference pertains to whether the user is already authenticated when initiating a transaction confirmation. This is expressed by which system invokes Nevis Mobile Authentication to trigger the transaction confirmation. The kind of invoking system, in turn, affects how to achieve user impersonation.

The two following scenarios illustrate the differences:

Scenario 1

A user transfers money from his bank account through the bank's e-banking application. This user authenticates when logging in to the e-banking application. He then issues the transaction.

Scenario 1 includes the following steps:

1. The user logs in to his/her e-banking application.
2. A transaction confirmation is issued by the e-banking application.

In this scenario, the user is authenticated in Nevis when the transaction is initiated; SecToken information is available and can be used to impersonate the user to issue the transaction.

Scenario 2

A user buys something from an online shop with his credit card. The credit card company requires the transaction to be signed before it is executed.

Scenario 2 contains the next steps:

1. The user buys an item in an online shop with his credit card.
2. The online shop contacts the payment backend.
3. A transaction confirmation is issued by the payment backend.

In this scenario, the user is not authenticated in Nevis when the transaction is initiated; SecToken information is not available. Here, either the payment backend impersonates the user and issues the transaction with the user's credentials (by creating a SecToken in the user's name). Or the payment backend is a trusted TLS client of Nevis Mobile Authentication and able to issue a transaction for any user.

info

Because user impersonation through a SecToken is more complex in the second scenario, the recommendation is to systematically use client-TLS. In this case, the payment backend acts as a trusted client of Nevis Mobile Authentication, which greatly simplifies user impersonation.

Example with Push Notification

This section describes the transaction confirmation process on the basis od the second scenario.

The numbers in the description below correspond with the numbers in the next figure.

1. The user completes his online shopping by performing a credit card checkout and supplying his credit card information.
2. The online shop contacts the payment backend to initiate the payment.
3. The payment backend contacts Nevis Mobile Authentication to initiate a transaction confirmation. The payment backend is responsible for determining the relying party backend username based on the provided payment information (e.g., the user's credit card information).
4. Nevis sends a push notification to the mobile device. If the user registered more than one mobile device, the backend must either:
   1. Decide which device should receive the push message, or.
   2. Send multiple messages to all devices registered to the user.
5. The mobile device receives the push notification and shows it in the notification bar. User interaction with the notification will open the mobile application, which is required to handle the push message data content.
6. The mobile application decrypts the push message and uses the contained data to contact Nevis to proceed with the FIDO transaction confirmation.
7. Nevis sends back the transaction content to the mobile application and requests the user to confirm the transaction.
8. The user confirms (or rejects) the transaction using the fingerprint-based FIDO Authenticator in the mobile device.
9. The transaction confirmation process on the mobile device is completed. The mobile application sends the confirmation result to Nevis.
10. The Nevis Authentication Backend informs the payment backend about the successfully signed transaction.
11. The payment backend confirms the payment to the online shop.
12. The online shop shows the payment as completed.

Technical Flow

info

The technical flow in the next figure explains the component interaction in detail. The step numbers in the figure do not correlate with the simplified example above.

In regard to the UAF protocol and flow, the steps in the transaction confirmation process and the Out-of-Band Authentication processes are the same. The authentication and transaction confirmation processes differ in the payload that accompanies the transaction confirmation process. This payload contains the transaction information; it is (usually) absent in authentication scenarios. The following technical flow therefore only contains the steps specific for the transaction confirmation process.

The numbers in the list correlate with the step numbers in the previous figure.

1. The user interacts with a third party web application which leads to a transaction, such as buying a book with this credit card in an online shop. The web application sends the transaction information to a relying party backend application. This backend application is capable of retrieving the missing required information to issue a transaction.

2. nevisProxy forwards the request to the relying party backend application.

3. The relying party backend application uses the provided transaction information (for example the credit card number) to resolve both the corresponding user stored in nevisIDM and the dispatch target ID of the user's mobile device.

   How the information is retrieved depends on the respective use case, the available information provided by the third party web application as well as the custom implementation of the relying party backend application.

4. The relying party backend application creates a GetUafRequest for the given username.

   References:

   • Authentication Request Service
   • GetUAFRequest Specification

5. The relying party backend application calls the nevisFIDO endpoint to dispatch a token request, and supplies the GetUafRequest together with the ID of the previously selected dispatch target (dispatchTargetId).

   Endpoint: https://<nevisFIDO-host>/nevisfido/token/dispatch/authentication

   References:

   • Dispatch Token Service

6. The relying party application uses the sessionId to query the status of the transaction confirmation operation. This sessionId has been provided as response in a previous, not described step.

   Endpoint: https://<nevisFIDO-host>:<nevisFIDO-port>/nevisfido/status

   References:

   • Status Service

7. The status service returns the status result for the current ongoing transaction confirmation operation.

   This operation is looped until the status response indicates success or failure of the transaction operation.

8. The relying party mobile application receives the AuthenticationRequest containing the transaction information, which it shows to the user on the mobile. The transaction information is either text- or image-based. It is up to the mobile application to choose the most suitable representation.

   The user has to decide whether to accept the transaction during the authentication process. The relying party mobile client application always returns an AuthenticationResponse to the server, even if the user rejected the transaction. In the latter case, the response contains the client error code indicating the user cancellation, instead of the signed transaction assertion.

9. The relying party backend application forwards the status response obtained from the nevisFIDO status service to the third party web application. The status response is most likely defined by the third party web application and must be mapped accordingly by the relying party backend application.

10. nevisProxy forwards the status response to the third party web application.

11. The third party web application that initiated the transaction confirmation processes the transaction according to the status response. That is, it marks the transaction as either confirmed or failed, depending on whether the user confirmed the transaction on his/her mobile device.

12. The transaction result is represented in the browser.

13. The user sees the transaction result (for example, a successful credit card payment).

The above technical flow applies to both scenarios described at the start of the chapter. In scenario 1 as well as scenario 2, the relying party backend application needs to access protected endpoints of the nevisFIDO component. Access can be granted in two ways:

• If the nevisFIDO instance is not using client-TLS, access is granted by providing a SecToken issued to the user who wants to initiate a transaction confirmation. In scenario 1, the SecToken is directly available as the user authenticated first. In scenario 2, the payment backend must be able to request a SecToken from Nevis in the name of the user.
• If the nevisFIDO instance is using client-TLS, access is granted implicitly, based on a valid client certificate (for more information, see Security Considerations).

The SecToken can be used in both scenarios, but user impersonation based on the SecToken is only easily available in scenario 1. For scenario 2, client-TLS based user impersonation is recommended.

Configuration Snippets

You will find example configuration snippets for all involved components in Nevis Component Configuration Examples.

Note that the described scenario of transaction confirmation does not involve nevisAuth. Therefore, map the required endpoints only in nevisProxy.