Operation Approval

Mobile-First Authentication uses a concept called “Operation” which is business transaction, for example login attempt, payment approval or any other sensitive transaction (3D secure, personal data change in internet banking etc).

The operation is created via the back-end API and delivered to the user’s mobile device for review. The user can then either approve or reject it.

Operation result is signed on the mobile device and delivered to the server where you can check operation details such as status, user ID or timestamp via the REST API. Bank’s systems can be optionally informed about status change via webhooks.

Operation is usually created for specific User ID but system also allows you to create so-called Non-Personalized Operations.

Operations are created based on a Operation Templates registered in the system that is filled with specific parameters. Template represents a type of an operation and defines parameters for each operation type. This way, you can create an operation, for example, for a payment with a particular amount.

Non-Personalized Operations

A non-personalized operation refers to an operation that is initiated without a specific User ID. In this state, the operation is not tied to a particular user and must be “claimed”.

It’s useful for some special use-cases such as QR Login in the Web App. In this scenario, non-personalized operation is created via backend, displayed on the internet banking login screen via QR code and claimed using mobile camera for particular user.

Operation result contains specific User ID as usual.

Operation Templates

Operation templates define how operation data is structured and interpreted in the mobile application during operation approval flows.

Different template types are used for different operation scenarios, for example payments, logins and other use cases.

Operation templates can be configured to define the structure of operation data and how it is presented in the mobile application.

The Generic template can be used for different types of operations with arbitrary structured data.

Authentication factors

It is possible to configure how authentication is handled for every operation type. This includes defining whether an operation should require:

• 1FA (e.g., possession factor only)
• 2FA, with the ability to choose the factor combination (possession + knowledge, possession + inherence, or both)

Managing UI

PowerAuth Enrollment Server supports UI extensions for operation templates.

UI extensions allow customization of how operation data is displayed in the mobile application during operation approval flows.

Localization

Operation templates support localization of UI elements displayed in the mobile application.

Localized values can be configured for:

• operation titles
• messages
• attribute labels

The language used for displaying operations in the mobile application is determined by the client application or the device settings.

Images in Templates

Operation templates support the inclusion of images in the UI definition.

Images can be configured as part of the template UI extension and are displayed in the mobile application together with operation details.

Operation Expiration

Every operation has an expiration time. An expired operation cannot be confirmed or rejected. In such cases, the server returns an error.

Operation Expiration is defined at the server level and can also be configured at the operation template level or overridden for a specific operation via an API request.

These levels define how the expiration time of an operation is determined:

• Server Level Expiration: Every operation has a default expiration time (5 minutes) defined on the server side
• Template Level Expiration: Operation templates can define an expiration time as part of their configuration. This value is then used when creating operations from the given template
• API-defined expiration: The expiration time of an operation can also be defined in the API request when creating an operation.

Pre-approval Screens

Pre-approval screens are optional screens with information that should be displayed before the operation approval to provide additional context and support informed decision-making.

Pre-approval Screen Types

Currently, the following types of pre-approval screen are supported.

• WARNING for warning screen.
• INFO for a general information screen.
• QR_SCAN for screen to scan QR code to do proximity check.

Post-approval Screen

Optional post approval screens define content displayed in the mobile application after an operation is approved or rejected.

Post-approval Screen Types

There are currently three types of post-approval screens available:

• REVIEW used when the user should see a structured summary of the completed operation.
• MERCHANT_REDIRECT used when the user should continue to another application screen or external system after completing the operation.
• GENERIC used for custom scenarios that require additional or application-specific data.