Skip to main content

Transaction Confirmation

Transaction confirmation lets a user authorize a specific operation, such as a payment, on a mobile device that holds a FIDO UAF credential. The user sees the transaction text in the mobile application and signs exactly that text, which is the FIDO principle of what you see is what you sign.

Technically it is an out-of-band authentication that carries an extra payload. The transaction typically starts on one device, for example a browser on a desktop computer, and is completed on another, the mobile device. Configure the services with the Transaction Confirmation Service pattern.

For the protocol flow and the two integration scenarios, see Out-of-Band Transaction Confirmation.

A dispatch channel is required

The pattern only exposes the services. It does not set up the channel that carries the transaction to the mobile device, and without such a channel the use case cannot work.

Configure the channel on the nevisFIDO UAF Instance pattern:

Push notification delivery is not guaranteed, so plan a fallback. See Dispatching for Out-of-Band Operations and Out-of-Band Channel Linking.

Configuring the Transaction Confirmation Service​

Add a Transaction Confirmation Service pattern to your project and fill in its fields:

  • Virtual Host(s): assign the virtual host on which the enabled endpoints are exposed.
  • Authentication Realm: optional here. Assign a realm if the endpoints on this virtual host are to be protected.
  • Application Access Token: the token propagated to the backend application to identify the authenticated user. Assign a Nevis SecToken pattern for applications that use Ninja, or a SAML token pattern for applications that consume SAML responses.
  • nevisFIDO: assign the nevisFIDO UAF Instance pattern that provides the transaction confirmation services.

Choosing the endpoints​

The pattern exposes several groups of endpoints, each of which can be enabled or disabled separately in the Endpoints tab. Start from the default configuration and disable the groups you do not need.

GroupCalled byContains
Token Dispatch Targets Query EndpointThe application on the first device/nevisfido/token/dispatch/targets, to find out which devices the user has registered
Token Dispatch EndpointsThe application on the first device/nevisfido/token/dispatch/authentication to dispatch the transaction, and /nevisfido/status to poll whether the user confirmed it
Token Redeem EndpointsThe mobile application on the second device/nevisfido/token/redeem/authentication, /nevisfido/uaf/1.1/facets and /nevisfido/uaf/1.1/authentication
Compat EndpointsOlder mobile applicationsLegacy aliases, including /auth/fidouaf/authenticationresponse/

Protect the dispatch targets query endpoint. It can be exposed as public for testing, but never in a production deployment, because it reveals which devices a given user has registered.

If the mobile application reaches Nevis on a different domain than the web application does, disable the token redeem endpoints here and expose them with a separate pattern on the other virtual host.

What the user confirms​

The transaction text is not part of the push notification. The two are set in different fields of the same dispatch request, and they serve different purposes:

  • The push notification content only alerts the user and opens the application. It travels through the push infrastructure unencrypted, so it must not contain amounts, account numbers or any other sensitive detail.
  • The transaction content is what the user reviews and signs inside the application. Put it in the context.transaction field of the GetUafRequest. nevisFIDO returns it to the application only after the application has redeemed the dispatched token.

For the payload structure, see Authentication Request Service. For a field-by-field comparison of the two, see Transaction Confirmation in the Access App documentation.

Behavior in the Nevis Access App​

  • The Access App supports text based transaction confirmation. See Transaction Confirmation for how the text is rendered and confirmed.
  • The user confirms with the registered authenticator. If biometrics are unavailable, the app falls back to the device passcode. See Biometric authentication with passcode fallback.
  • Number matching can be enabled so the user has to reproduce a number shown on the first device, which defends against confirmation fatigue.
  • For the delivery mechanism itself, see Push messages.