From f20d4f2a31dc19e46e2d5d09a7f5f99aee86e2eb Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 10:49:33 +0800
Subject: [PATCH 01/16] Initial transfer of Mobile Token documentation from Web
 Flow

---
 docs/Mobile-Push-Registration-API.md | 114 +++++++++
 docs/Mobile-Token-Operations-API.md  | 241 +++++++++++++++++++
 docs/Offline-Signatures-QR-Code.md   | 280 ++++++++++++++++++++++
 docs/Operation-Data.md               | 152 ++++++++++++
 docs/Operation-Form-Data.md          | 346 +++++++++++++++++++++++++++
 docs/_Sidebar.md                     |   5 +
 6 files changed, 1138 insertions(+)
 create mode 100644 docs/Mobile-Push-Registration-API.md
 create mode 100644 docs/Mobile-Token-Operations-API.md
 create mode 100644 docs/Offline-Signatures-QR-Code.md
 create mode 100644 docs/Operation-Data.md
 create mode 100644 docs/Operation-Form-Data.md

diff --git a/docs/Mobile-Push-Registration-API.md b/docs/Mobile-Push-Registration-API.md
new file mode 100644
index 000000000..4fdaabb43
--- /dev/null
+++ b/docs/Mobile-Push-Registration-API.md
@@ -0,0 +1,114 @@
+# Mobile Push Registration API
+
+In order to register mobile device to the push notifications, following endpoints are published.
+
+## Endpoints
+
+### Register for Push Notifications
+
+Registers a device to push notifications.
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/push/device/register/token</code></td>
+    </tr>
+</table>
+
+#### Request
+
+- Headers:
+    - `Content-Type: application/json`
+    - `X-PowerAuth-Token: ...`
+
+```json
+{
+  "requestObject": {
+      "platform": "ios",
+      "token": "10de0b9c-791f-4e9f-93c4-e2203951c307"
+  }
+}
+```
+
+Supported platforms:
+- `ios`
+- `android`
+
+#### Success Response
+- Status Code: `200`
+- Headers:
+    - `Content-Type: application/json`
+
+```json
+{
+  "status": "OK"
+}
+```
+
+#### Error Response - Push Registration Failed
+- Returned when Push Server returns error during registration.
+- Status Code: `400`
+- Headers:
+    - `Content-Type: application/json`
+
+```json
+{
+    "status": "ERROR",
+    "responseObject": {
+        "code": "PUSH_REGISTRATION_FAILED",
+        "message": "Push registration failed in Mobile Token API component."
+    }
+}
+```
+
+#### Error Response - PowerAuth Authentication Failed
+- Returned when PowerAuth authentication fails.
+- Status Code: `401`
+- Headers:
+    - `Content-Type: application/json`
+
+```json
+{
+    "status": "ERROR",
+    "responseObject": {
+        "code": "POWERAUTH_AUTH_FAIL",
+        "message": "Unable to verify device registration"
+    }
+}
+```
+
+#### Error Response - Invalid Request Object
+- Returned when request object is invalid.
+- Status Code: `400`
+- Headers:
+    - `Content-Type: application/json`
+
+```json
+{
+    "status": "ERROR",
+    "responseObject": {
+        "code": "INVALID_REQUEST",
+        "message": "Invalid request object sent to Mobile Token API component."
+    }
+}
+```
+
+#### Error Response - Invalid Activation
+- Returned when application or activation is invalid.
+- Status Code: `400`
+- Headers:
+    - `Content-Type: application/json`
+
+```json
+{
+    "status": "ERROR",
+    "responseObject": {
+        "code": "INVALID_ACTIVATION",
+        "message": "Invalid activation found in Mobile Token API component."
+    }
+}
+```
diff --git a/docs/Mobile-Token-Operations-API.md b/docs/Mobile-Token-Operations-API.md
new file mode 100644
index 000000000..f26d93414
--- /dev/null
+++ b/docs/Mobile-Token-Operations-API.md
@@ -0,0 +1,241 @@
+# Mobile Token API for Operations
+
+Mobile token API provides access to operations.
+
+The generated REST API documentation in deployed Enrollment server, and it includes standard PowerAuth RESTful API:
+
+```
+http[s]://[host]:[port]/enrollment-server/swagger-ui.html
+```
+
+## Mobile API Error Codes
+
+List of error codes in Mobile Token API:
+
+| Code | Description | HTTP Status Code |
+|---|---|---|
+| `INVALID_REQUEST` | Invalid request sent - missing request object in request | 400 |
+| `INVALID_ACTIVATION` | Activation is not valid (it is different from configured activation). Return this error in case the activation does not exist, or in case the activation is not allowed to perform the action (for example, user did not allow operation approvals on such device). | 400 |
+| `POWERAUTH_AUTH_FAIL` | PowerAuth authentication failed | 401 |
+| `OPERATION_ALREADY_FINISHED` | Operation is already finished | 400 |
+| `OPERATION_ALREADY_FAILED` | Operation is already failed | 400 |
+| `OPERATION_ALREADY_CANCELED` | Operation is already canceled | 400 |
+| `OPERATION_EXPIRED` | Operation is expired | 400 |
+
+## Localization
+
+In order to get a correctly localized response, please use the `Accept-Language` HTTP header in your request.
+
+## Mobile Token API Endpoints
+
+### Get Pending Operations
+
+Get the list with all operations that are pending confirmation.
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/auth/token/app/operation/list</code></td>
+    </tr>
+</table>
+
+#### Request
+
+- Headers:
+    - `Content-Type: application/json`
+    - `Accept-Language: en-US`
+    - `X-PowerAuth-Token: ...`
+
+```json
+{}
+```
+
+#### Response
+- Status Code: `200`
+- Headers:
+    - `Content-Type: application/json`
+
+```json
+{
+  "status": "OK",
+  "responseObject": [
+    {
+      "id": "7e0ba60f-bf22-4ff5-b999-2733784e5eaa",
+      "name": "authorize_payment",
+      "data": "A1*A100CZK*Q238400856/0300**D20190629*NUtility Bill Payment - 05/2019",
+      "operationCreated": "2018-07-02T14:43:13+0000",
+      "operationExpires": "2018-07-02T14:48:17+0000",
+      "allowedSignatureType": {
+        "type": "2FA",
+        "variants": [
+          "possession_knowledge",
+          "possession_biometry"
+        ]
+      },
+      "formData": {
+        "title": "Confirm Payment",
+        "message": "Hello,\nplease confirm following payment:",
+        "attributes": [
+          {
+            "type": "HEADING",
+            "id": "operation.heading",
+            "label": "Utility Payment"
+          },
+          {
+            "type": "AMOUNT",
+            "id": "operation.amount",
+            "label": "Amount",
+            "amount": 100,
+            "currency": "CZK",
+            "amountFormatted": "100,00",
+            "currencyFormatted": "Kč"
+          },
+          {
+            "type": "KEY_VALUE",
+            "id": "operation.account",
+            "label": "To Account",
+            "value": "238400856/0300"
+          },
+          {
+            "type": "KEY_VALUE",
+            "id": "operation.dueDate",
+            "label": "Due Date",
+            "value": "Jun 29, 2019"
+          },
+          {
+            "type": "NOTE",
+            "id": "operation.note",
+            "label": "Note",
+            "note": "Utility Bill Payment - 05/2019"
+          },
+          {
+            "type": "PARTY_INFO",
+            "id": "operation.partyInfo",
+            "label": "Application",
+            "partyInfo": {
+              "logoUrl": "https://itesco.cz/img/logo/logo.svg",
+              "name": "Tesco",
+              "description": "Find out more about Tesco...",
+              "websiteUrl": "https://itesco.cz/hello"
+            }
+          }
+        ]
+      }
+    }
+  ]
+}
+```
+
+### Confirm Operation
+
+Confirms an operation with given ID and data. This endpoint requires a signature of a type specified by the operation.
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/auth/token/app/operation/authorize</code></td>
+    </tr>
+</table>
+
+#### Request
+
+- Headers:
+    - `Content-Type: application/json`
+    - `X-PowerAuth-Authorization: ...`
+
+```json
+{
+  "requestObject": {
+    "id": "3699a9c0-45f0-458d-84bc-5bde7ec384f7",
+    "data": "A1*A100CZK*Q238400856\/0300**D20190629*NUtility Bill Payment - 05\/2019"
+  }
+}
+```
+
+#### Response
+- Status Code: `200`
+- Headers:
+    - `Content-Type: application/json`
+
+```json
+{
+  "status": "OK"
+}
+```
+
+### Reject Operation
+
+Reject an operation with given ID, with a provided reason.
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/auth/token/app/operation/cancel</code></td>
+    </tr>
+</table>
+
+#### Request
+
+- Headers:
+    - `Content-Type: application/json`
+    - `X-PowerAuth-Authorization: ...`
+
+```json
+{
+  "requestObject": {
+    "id": "352d6cfa-b8d7-4366-af1f-c99b071b4dc4",
+    "reason": "INCORRECT_DATA"
+  }
+}
+```
+
+#### Response
+- Status Code: `200`
+- Headers:
+    - `Content-Type: application/json`
+
+```json
+{
+  "status": "OK"
+}
+```
+
+## Enumerations
+
+### Form Attribute Types
+
+| Type | Description |
+|---|---|
+| `AMOUNT` | Form field representing an amount with currency. |
+| `KEY_VALUE` | Form field representing a key value item, where items are displayed next to each other. This realistically impose limitation on value length - it should fit into the single line. |
+| `NOTE` | Form field representing a generic text note, where label is displayed above the note. As a result, note can be of an arbitrary length and can be multi-line. |
+| `HEADING` | Form field representing a heading, where label is displayed as the heading text. |
+| `PARTY_INFO` | Form field representing a structured object with information about a third party. |
+
+### Operation Rejection Reasons
+
+| Type | Description |
+|---|---|
+| `UNKNOWN` | User decided not to tell us the operation rejection reason. |
+| `INCORRECT_DATA` | User claims incorrect data was presented in mToken app. |
+| `UNEXPECTED_OPERATION` | User claims he/she did not expect any operation. |
+
+### Allowed Signature Types
+
+| Type | Description |
+|---|---|
+| `1FA` | One-factor signature - user just has to tap "Confirm" button to confirm it. |
+| `2FA` | Two-factor signature - user needs to use either password of biometry as addition to possession factor. The `variants` key then determines what signature type is allowed for the given operation. |
+| `ECDSA` | ECDSA signature with device private key. |
diff --git a/docs/Offline-Signatures-QR-Code.md b/docs/Offline-Signatures-QR-Code.md
new file mode 100644
index 000000000..deff55a47
--- /dev/null
+++ b/docs/Offline-Signatures-QR-Code.md
@@ -0,0 +1,280 @@
+# Off-line Signature QR Code
+
+## Table of Contents
+
+- [Introduction](#introduction)
+- [Operation Attributes](#operation-attributes)
+- [Operation Data](#operation-data)
+- [Flags](#flags)
+- [Signature Calculation](#signature)
+- [Forward Compatibility](#forward-compatibility)
+- [Offline Signature Process Description](#offline-signature-process-description)
+
+## Introduction
+
+This chapter describes how operation data is encoded into QR code for the purpose of off-line verification.
+
+## Operation Attributes
+
+The format of QR code for offline operations is a high density string composed from several main operation attributes:
+
+1. `{OPERATION_ID}` - operation identifier (UUID like identifier)
+2. `{TITLE}` - title for operation, in UTF8 format. For example: "Payment".
+   - ASCII control characters (code < 32) are forbidden
+   - `\n` can be used for newline character
+   - `\\` can be used for backslash
+3. `{MESSAGE}` - message associated with operation, in UTF8 format. For example: "Please confirm this playment"
+   - ASCII control characters (code < 32) are forbidden
+   - `\n` can be used for newline character
+   - `\\` can be used for backslash
+4. `{OPERATION_DATA}` - content of operation data
+5. `{FLAGS}` - various flags affecting how operation is processed
+6. `{NONCE_B64}` - nonce, 16 random bytes in Base64 format. Required for pure offline signature.
+7. `{SIGNING_KEY_TYPE}{ECDSA_QRDATA_SIGNATURE_BASE64}` - ECDSA signature in Base64 format. The signature string has an one prefix character, containing an information about signing key type.
+
+Then, the final string for QR code is simple, new-line separated list of attributes:
+
+```
+{OPERATION_ID}\n
+{TITLE}\n
+{MESSAGE}\n
+{OPERATION_DATA}\n
+{FLAGS}\n
+{NONCE_B64}\n
+{SIGNING_KEY_TYPE}{ECDSA_QRDATA_SIGNATURE_BASE64}
+```
+
+For example:
+```
+5ff1b1ed-a3cc-45a3-8ab0-ed60950312b6
+Payment
+Please confirm this payment
+A1*A100CZK*ICZ2730300000001165254011*D20180425
+B
+AD8bOO0Df73kNaIGb3Vmpg==
+0MEYCIQDby1Uq+MaxiAAGzKmE/McHzNOUrvAP2qqGBvSgcdtyjgIhAMo1sgqNa1pPZTFBhhKvCKFLGDuHuTTYexdmHFjUUIJW=
+```
+
+## Operation Data
+
+Operation data is an asterisk separated list of fields, where the first field defines a version of operation data and template. Other fields are additional and contains typically significant attributes, which has to be presented to the user, before the operation is confirmed and signed.
+
+An exact details of the operation data structure can be found in the separate documentation:
+
+- [Operation Data Structure](./Operation-Data.md)
+
+## Flags
+
+`{FLAGS}` attribute is a string of characters, where each character represents one flag. Order of characters in string is not important.
+
+| Flag | Meaning                      |
+|------|:-----------------------------|
+| `B`  | Operation can be signed with biometric factor |
+
+Examples:
+- `B` - biometric 2FA is allowed
+- ` ` (empty string) - only knowledge factor is allowed for 2FA
+
+## Signature
+
+Signature attribute is composed from two separate fields:
+- `{SIGNING_KEY_TYPE}` is one character defining which key was used for signature calculation. Available options are:
+   - `0` - `KEY_SERVER_MASTER_PRIVATE` was used for ECDSA signature calculation
+   - `1` - `KEY_SERVER_PRIVATE` personalized key was used for ECDSA signature calculation
+- `{ECDSA_QRDATA_SIGNATURE_BASE64}` is ECDSA signature calculated with selected private key.
+
+Then the signed data payload is composed as:
+
+```
+{OPERATION_ID}\n
+{TITLE}\n
+{MESSAGE}\n
+{OPERATION_DATA}\n
+{FLAGS}\n
+{NONCE_B64}\n
+{SIGNING_KEY_TYPE}
+```
+
+## Forward Compatibility
+
+The data format is designed with forward compatibility in mind. This means that QR codes issued in newer data format can be processed in older data parsers. This is possible due to following contract rules:
+
+- Rules for operation attributes:
+  - `{NONCE_B64}`, `{SIGNING_KEY_TYPE}`, `{SIGNATURE_B64}` are always last attributes in the string and
+    ECDSA signature is always calculated for all attributes listed before the signature attribute.
+  - If a new operation attribute needs to be added, then it has to be inserted as a new line, before `{NONCE_B64}`.
+  - For Example:
+    ```
+    {OPERATION_ID}\n
+    {TITLE}\n
+    {MESSAGE}\n
+    {OPERATION_DATA}\n
+    {FLAGS}\n
+    {XXX_NEW_ATTRIBUTE}\n
+    {NONCE_B64}\n
+    {SIGNING_KEY_TYPE}{ECDSA_QRDATA_SIGNATURE_BASE64}
+    ```
+    then, the signature will be calculated from following data:
+    ```
+    {OPERATION_ID}\n
+    {TITLE}\n
+    {MESSAGE}\n
+    {OPERATION_DATA}\n
+    {FLAGS}\n
+    {XXX_NEW_ATTRIBUTE}\n
+    {NONCE_B64}\n
+    {SIGNING_KEY_TYPE}
+    ```
+- Rules for data fields and templates:
+  - All unsupported data fields are treated as `T{TEXT}` (e.g. arbitrary attribute with text as it is)
+  - All unsupported templates are treated as [`0` Generic](./Operation-Data.md#0-generic)
+
+## Offline Signature Process Description
+
+The general principles of using offline signatures in PowerAuth are documented in chapter [Offline Signatures](https://github.com/wultra/powerauth-server/blob/develop/docs/Offline-Signatures.md). This chapter provides an more detailed description of the step-by-step process.
+
+There are three stages of offline signature verification:
+
+1) Generate QR code and display it to the user.
+2) User uses mobile app to scan the QR code and compute offline signature.
+3) Verify the offline signature.
+
+### 1. Generate QR Codes
+
+The first step of the process is to generate a QR code to be displayed to the user.
+
+#### 1.1. Construct offline signature data payload:
+
+First, you need to prepare a QR code data stup from the information you already should know - operation ID, operation title and description, operation data and additional flags:
+
+```
+{OPERATION_ID}\n
+{TITLE}\n
+{MESSAGE}\n
+{OPERATION_DATA}\n
+{FLAGS}
+```
+
+For example:
+
+```
+5ff1b1ed-a3cc-45a3-8ab0-ed60950312b6
+Payment
+Please confirm this payment
+A1*A100CZK*ICZ2730300000001165254011*D20180425
+B
+```
+
+The meaning of individual fields is explained in chapter [Operation Attributes](#operation-attributes). Note that the field values should be normalized as discussed in the same chapter.
+
+#### 1.2. Fetch Data For Offline Signatures
+
+Now, you need to prepare the data for the QR code display. Call the PowerAuth REST method to create a personalized offline signature payload. The REST method `createPersonalizedOfflineSignaturePayload` requires two parameters:
+
+- `activationId` - ID of the activation of mobile device
+- `data` - data constructed in step 1
+
+The REST method is documented in the [PowerAuth documentation](https://github.com/wultra/powerauth-server/blob/develop/docs/WebServices-Methods.md#method-createpersonalizedofflinesignaturepayload).
+
+In the response from the REST method `createPersonalizedOfflineSignaturePayload`, you will receive:
+
+- `offlineData` - The exact data to be displayed inside the QR code.
+- `nonce` - A random cryptographic nonce.
+
+The `nonce` field is available separately in response, so that it can be used for signature verification later, as documented in [Offline Signatures](https://github.com/wultra/powerauth-server/blob/develop/docs/Offline-Signatures.md#verifying-offline-signatures).
+
+Note: The format of the `offlineData` is the following:
+
+```
+{DATA}\n{NONCE_B64}\n{KEY_SERVER_PRIVATE_INDICATOR}{ECDSA_QRDATA_SIGNATURE_BASE64}
+```
+
+As you can see, the `offlineData` already contain `nonce` value (in Base64 format) since the mobile app needs to scan the `nonce` value to compute the signature. However, the REST service still returns the value separately - since `nonce` must be used later on the back-end side, we wanted to avoid the necessity to parse the `offlineData` and hence we return `nonce` as a standalone response attribute.
+
+#### 1.3. Display Data To The User
+
+To display QR code in the web browser, generate the QR code from `offlineData` you obtained in 1.2 (no changes to the data are needed).
+
+Code example in Java:
+
+```java
+            BitMatrix matrix = new MultiFormatWriter().encode(
+                    new String(offlineData.getBytes("UTF-8"), "ISO-8859-1"),
+                    BarcodeFormat.QR_CODE,
+                    size,
+                    size);
+            BufferedImage image = MatrixToImageWriter.toBufferedImage(matrix);
+            ByteArrayOutputStream baos = new ByteArrayOutputStream();
+            ImageIO.write(image, "png", baos);
+            byte[] bytes = baos.toByteArray();
+            return "data:image/png;base64," + BaseEncoding.base64().encode(bytes);
+```
+
+The user can now scan the QR code via the mobile token app.
+
+The value of `nonce` must be stored somewhere - for example on a browser level, either as a hidden HTML form input field or as a JavaScript variable, or alternatively, it can be stored in the user session by the specific operation. The `nonce` value is required for later offline signature validation, see step 3.
+
+### 2. Computing Signatures on Mobile Device
+
+#### 2.1. Verify ECDSA Signature of Offline Data
+
+After user scans the QR code using a mobile app, the `ECDSA_QRDATA_SIGNATURE_BASE64` should be validated on mobile device to verify authenticity of received data by taking contents of `offlineData` before the `ECDSA_QRDATA_SIGNATURE_BASE64` and computing the ECDSA signature using `KEY_SERVER_PRIVATE`. Both signatures must match before continuing with the offline data signature verification.
+
+#### 2.2. Computing the Signature
+
+Mobile device prompts the user for the PIN code or use of a biometry and computes 4x4 digit long authentication code to be rewritten manually.
+
+### 3. Validating the Signature
+
+#### 3.1. Processing The User Input
+
+After user enters 4x4 digits in the browser, the value must be converted into a standard PowerAuth signature format that uses 2x8 digits. For example, an offline signature `1234-5678-9012-3456` needs to be converted into `12345678-90123456` (removing 1st and 3rd dash).
+
+#### 3.2. Preparing Signature Base String
+
+Now, you need to prepare a normalized data package called "signature base string". This is the payload that mobile app used to compute the signature - you need to have the same signature base string in order to be able to verify the signature.
+
+To compute the signature base string, you need:
+
+- `data` - data for off-line signature verification are built from `operationId` and `operationData` attributes in a following way:
+  - format: `${operationId}&${operationData}` (values separated by `&` character)
+  - example: `9326edcd-5375-4847-abd1-5eacb6d95125&A1*A100CZK*ICZ2730300000001165254011`
+    - Payment operation with ID `9326edcd-5375-4847-abd1-5eacb6d95125`, where data is `A1*A100CZK*ICZ2730300000001165254011` (representing amount of "100 CZK" to IBAN account "CZ2730300000001165254011")
+- `nonce` value (as obtained in 1.2)
+- two static constants: `POST` and `/operation/authorize/offline`
+
+The [algorithm for signature data normalization](https://developers.wultra.com/docs/develop/powerauth-crypto/Computing-and-Validating-Signatures#normalized-data-for-http-requests) is available in the cryptography description.
+
+The Java class [PowerAuthHttpBody](https://github.com/wultra/powerauth-crypto/blob/master/powerauth-java-http/src/main/java/io/getlime/security/powerauth/http/PowerAuthHttpBody.java) already contains a ready to use method for computing the normalized signature base string:
+
+```java
+String signatureBaseString
+    = PowerAuthHttpBody.getSignatureBaseString(
+        "POST",
+        "/operation/authorize/offline",
+        BaseEncoding.base64().decode(nonce),
+        data.getBytes()
+);
+```
+
+#### 3.4. Verifying Signature
+
+To verify signature, you need to call the REST method [`verifyOfflineSignature`](https://github.com/wultra/powerauth-server/blob/develop/docs/WebServices-Methods.md#method-verifyofflinesignature) providing:
+
+- `activationId` - identifier of the activation (to know which device is responsible for verification)
+- `data` (represented by `signatureBaseString` as obtained in 3.2.) - as data for verification
+- `signature` - value of the signature entered by the user (as obtained in 3.1., 2x8 digits)
+- `biometryAllowed` - whether biometry signature factor is allowed
+
+The method returns information about signature verification:
+
+- `signatureValid` You can use this value to determine if the signature verification was successful or not.
+- `activationStatus` - Activation status after this attempt of the signature validation.
+- `blockedReason` - In case the activation is blocked, this attribute contains additional info about the reason.
+- `activationId` - Activation ID used for validating the signature.
+- `userId` - User ID associated with the activation who authenticated to compute the signature.
+- `applicationId` - Application ID of the application that is associated with given activation ID and was used to compute the signature.
+- `signatureType` - Signature type that was used to compute the signature value.
+- `remainingAttempts` - How many attempts are remaining for the signature validation (single, activation related counter).
+
+See the REST method documentation for details.
diff --git a/docs/Operation-Data.md b/docs/Operation-Data.md
new file mode 100644
index 000000000..1bf9a6ad9
--- /dev/null
+++ b/docs/Operation-Data.md
@@ -0,0 +1,152 @@
+# Operation Data Structure
+
+## Table of Contents
+
+- [Operation Data Overview](#operation-data-overview)
+    - [Header](#header)
+    - [Known Template Types](#known-template-types)
+    - [Data Types](#data-types)
+    - [Data Fields](#data-fields)
+- [Template Details](#template-details)
+    - [`0` Generic](#0-generic)
+    - [`1` Payment](#1-payment)
+    - [`2` Login Request](#2-login-request)
+
+## Operation Data Overview
+
+Operation data is an asterisk separated list of fields, where the first field defines a version of operation data and template. Other fields are additional and typically contain significant attributes, which has to be presented to the user, before the operation is confirmed and signed.
+
+Each field has its unique type, defined by first letter. For example, following string contains header `A1` and three additional fields: "Amount", "Account" and "Date":
+
+```
+A1*A100CZK*ICZ2730300000001165254011*D20180425
+```
+
+### Header
+
+Header is composed from two parts:
+
+- `{VERSION}{TEMPLATE}`, where
+    - `{VERSION}` is an one capital letter defining version of operation data. First version is `A`, then `B`, `C`, etc...
+    - `{TEMPLATE}` is a decimal number defining a template which helps with other fields interpretation.
+
+Version `A` has following limitations:
+
+- Templates from `0` up to `99` are supported
+- Up to 5 additional fields are supported
+
+### Known Template Types
+
+- `0` - Generic template. Each field will be displayed with "default" title.
+- `1` - Payment data
+- `2` - Login confirmation
+
+If template defines an optional field and this field is not present in operation data, then an empty string can be used. For example, following strings defines various forms of payment:
+
+- `A1*A100CZK*ICZ2730300000001165254011***` - all optional parameters are empty
+- `A1*A100CZK*ICZ2730300000001165254011` - the same as above, but with omitted asterisks
+- `A1*A100CZK*ICZ2730300000001165254011***Nnote for recipient` - Last note is optional but used, so asterisks must be used to put note field at the right position.
+
+_Note: Templates other than `0` may have an implicit `{TITLE}` and `{MESSAGE}` attributes displayed on the client side (in the mobile application). For example, it's not required to issue "Payment" and "Please confirm this payment" titles, when the "payment" template is used, simple an empty newline can be used for both data attributes. This rule unfortunately goes agains our forward compatibility principle, so it's recommended only for version `A` templates. Unless data capacity is a critical issue, we recommend using explicit title and message._
+
+### Data Types
+
+This section defines data types available for data fields:
+
+- `{DECIMAL}` - a decimal number with dot as decimal separator. The Examples:
+    - `100.10` - number with a fractional part
+    - `1492` - number without a fractional part
+
+- `{CURRENCY}` - Currency code from [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217)
+
+- `{IBAN}` - Fully qualified IBAN with optional, comma separated BIC. For example:
+    - `CZ2730300000001165254011` - IBAN without BIC code
+    - `CZ2730300000001165254011,AIRACZPP` - IBAN with BIC code
+
+- `{TEXT}` - UTF-8 encoded text with few escaped characters:
+    - `\n` - newline
+    - `\\` - escape for backslash
+    - `\*` - escape for asterisk
+    - All characters with ASCII code < 32 are forbidden (e.g. `\t` should not be in the string)
+    - In the QR code generator, it is recommended to compress spaces. That means that two and more consequent space characters should be replaced with just one space character.
+
+### Data Fields
+
+- `A{DECIMAL}{CURRENCY}` - **Amount** with currency.
+    - `A100CZK`
+    - `A1492.50EUR`
+    - **"Amount"** is a default title, when template is not recognized.
+
+- `I{IBAN}` - **Counter account** in IBAN format, with optional BIC code:
+    - `ICZ2730300000001165254011`
+    - `ICZ2730300000001165254011,AIRACZPP`
+    - **"Account"** is a default title, when template is not recognized.
+
+- `Q{TEXT}` - **Counter account** in arbitrary format:
+    - `Q1165254011/3030` - an example for czech account
+    - **"Account"** is a default title, when template is not recognized.
+
+- `D{DATE}` - **date field** in `YYYYMMDD` format. For example:
+    - `D20180425`
+    - **"Date"** is a default title
+
+- `R{TEXT}` - **Operation's reference**. This field contains a general reference associated with the operation. For example, for payment it can be a payment reference or in case of czech domestic payment, for trasmission of symbols asscociated with payment:
+    - `RID3343432434` - some payment reference
+    - `R/VS123456/SS345/KS` - Czech specific, defines: VS=123456, SS=345, KS=empty
+    - **"Reference"** is a default title
+
+- `N{TEXT}` - **Note** associated with the operation. It can be for example note associated with the payment.
+    - `NZa vecerne pivo`
+    - **"Note"** is a default title
+
+- `T{TEXT}` - **Arbitrary textual** field, displayed as is, without any additional processing.
+    - `TRate 1EUR = 25,49CZK`
+    - **Attribute N**, is a default title, where N is an auto incremented number, starting with 1. For example, if you use two `T` fields in data, then the first in row will have "Attribute 1" and second "Attributer 2" title.
+
+## Template Details
+
+### `0` Generic
+
+Generic template has no predefined order of fields. You can use up to 5 fields with any type in the operation data. Note that `{TITLE}` and `{MESSAGE}` data attributes are required for this kind of template.
+
+### `1` Payment
+
+*Available since version `A`*
+
+| Attribute | Title                        |
+|-----------|:-----------------------------|
+| Title     | Payment                      |
+| Message   | Please confirm this payment  |
+
+Data fields
+
+| # | Type | Title                        | Required |
+|---|:------:|:-----------------------------|:--------:|
+| 1 | A      | Amount                       | yes      |
+| 2 | I or Q | Counter account              | yes      |
+| 3 | R      | Payment Reference (or parsed symbols in CZ) | |
+| 4 | D      | Due date                     |          |
+| 5 | N      | Note                         |          |
+
+Example operation data:
+
+```
+A1*A100CZK*ICZ2730300000001165254011*R/VS123456/SS/KS*D20180425
+```
+
+### `2` Login Request
+
+*Available since version `A`*
+
+| Attribute | Title                        |
+|-----------|:-----------------------------|
+| Title     | Login request                |
+| Message   | Please confirm login into internet banking. |
+
+Data fields for this type of teplate are not specified, so any available fields will be interpreted as for generic template.
+
+Example operation data:
+
+```
+A2
+```
diff --git a/docs/Operation-Form-Data.md b/docs/Operation-Form-Data.md
new file mode 100644
index 000000000..7f79a41a2
--- /dev/null
+++ b/docs/Operation-Form-Data.md
@@ -0,0 +1,346 @@
+# Customizing Operation Form Data
+
+When creating an operation, you can customize the operation form data. This customization has an effect on how the operation form data is displayed during the operation review step.
+
+The customization should be done by the client which initiates the operation before the authentication process is initiated.
+
+For more information about operation form data see the [Next Step REST API](./Next-Step-Server-REST-API-Reference.md#operation-formdata).
+
+## Standard Operation Form Data Attributes
+
+Following attributes are required to be specified for each operation:
+- `title` - title of the operation
+- `greeting` - message for the user related to the operation displayed in web interface
+- `summary` - summary of the operation shown in push messages
+
+## Custom Operation Form Data Attributes
+
+Following structured custom form data attributes are available:
+- `AMOUNT` - amount with currency
+- `NOTE` - free text
+- `BANK_ACCOUNT_CHOICE` - choice of a bank account
+- `KEY_VALUE` - generic key-value field
+- `BANNER` - banner which is displayed above form field
+- `HEADING` - heading with label 
+- `PARTY_INFO` - information about party
+
+## Value Formatting
+
+Following form data attributes support value formatting:
+- `AMOUNT`
+- `NOTE`
+- `KEY_VALUE`
+- `HEADING`
+
+The value is formatted based on specified format type. The following format types can be used:
+- `TEXT` - value is not formatted
+- `LOCALIZED_TEXT` - value is localized using localization key from message resources
+- `DATE` - value is formatted as date using current locale, expected value format is YYYY-MM-DD
+- `NUMBER` - value is formatted as number using current locale
+- `AMOUNT` - value is formatted as amount with currency using current locale
+- `ACCOUNT` - value is not formatted (reserved for future use)
+
+## Resource Localization
+
+Form data labels are specified using localization key, such as "operation.title". This key is localized using resources. See chapter [Customizing Web Flow Appearance](https://github.com/wultra/powerauth-webflow-customization/blob/develop/docs/Customizing-Web-Flow-Appearance.md) for details about updating resources.
+
+Form data value localization for custom attributes:
+- Form data values are localized in case they use the `LOCALIZED_TEXT` value format type.
+- Currency in `AMOUNT` form data type is localized using message resource: `currency.[currency].name`.
+
+Other form data values are not localized and are displayed as received.
+
+## Resource Translation
+
+Resource translation is process of inserting other form data values into existing values.
+
+Example:
+```
+operation.summary=Hello, please confirm payment {operation.amount} {operation.currency} to account {operation.account}.
+```
+
+Summary is translated into:
+```
+operation.summary=Hello, please confirm payment 100 CZK to account 12345678/0123.
+```
+
+Resource translation is performed on following attribute values:
+- `title`
+- `greeting`
+- `summary`
+
+## Java API for Operation Form Data
+
+See example below:
+```java
+
+// variable definition
+String account = "238400856/0300";
+BigDecimal amount = BigDecimal.valueOf(100);
+String currency = "CZK";
+String note = "Utility Bill Payment - 05/2019";
+String dueDate = "2019-06-29";
+
+// operation form data initialization
+OperationFormData formData = new OperationFormData();
+formData.addTitle("operation.title");
+formData.addGreeting("operation.greeting");
+formData.addSummary("operation.summary");
+formData.addAmount("operation.amount", amount, "operation.currency", currency);
+formData.addKeyValue("operation.account", account, ValueFormatType.ACCOUNT);
+formData.addKeyValue("operation.dueDate", dueDate, ValueFormatType.DATE);
+formData.addNote("operation.note", note, ValueFormatType.TEXT);
+
+// sample operation configuration for bank account choice select
+OperationFormFieldConfig bankAccountConfig = new OperationFormFieldConfig();
+bankAccountConfig.setId("operation.bankAccountChoice");
+bankAccountConfig.setEnabled(false);
+bankAccountConfig.setDefaultValue("CZ4043210000000087654321");
+formData.getConfig().add(bankAccountConfig);
+
+// operation initialization
+final ObjectResponse<CreateOperationResponse> payment = client.createOperation("authorize_payment", data, formData, null, applicationContext);
+session.setAttribute("operationId", payment.getResponseObject().getOperationId());
+```
+
+## Decorating Operation Form Data in Data Adapter
+
+Operation form data can be decorated in Data Adapter by implementing method `decorateFormData`. The additional form attributes appear during the operation review step (after the user was authenticated and operation authorization is required).
+
+### Adding bank account choice
+
+The example below decorates operation form data -- three bank accounts are added to the `BANK_ACCOUNT_CHOICE` attribute:
+```java
+List<BankAccount> bankAccounts = new ArrayList<>();
+
+BankAccount bankAccount1 = new BankAccount();
+bankAccount1.setName("Běžný účet v CZK");
+bankAccount1.setBalance(new BigDecimal("24394.52"));
+bankAccount1.setNumber("12345678/1234");
+bankAccount1.setAccountId("CZ4012340000000012345678");
+bankAccount1.setCurrency("CZK");
+bankAccounts.add(bankAccount1);
+
+BankAccount bankAccount2 = new BankAccount();
+bankAccount2.setName("Spořící účet v CZK");
+bankAccount2.setBalance(new BigDecimal("158121.10"));
+bankAccount2.setNumber("87654321/4321");
+bankAccount2.setAccountId("CZ4043210000000087654321");
+bankAccount2.setCurrency("CZK");
+bankAccounts.add(bankAccount2);
+
+BankAccount bankAccount3 = new BankAccount();
+bankAccount3.setName("Spořící účet v EUR");
+bankAccount3.setBalance(new BigDecimal("1.90"));
+bankAccount3.setNumber("44444444/1111");
+bankAccount3.setAccountId("CZ4011110000000044444444");
+bankAccount3.setCurrency("EUR");
+bankAccount3.setUsableForPayment(false);
+bankAccount3.setUnusableForPaymentReason(dataAdapterI18NService.messageSource().getMessage("operationReview.balanceTooLow", null, LocaleContextHolder.getLocale()));
+bankAccounts.add(bankAccount3);
+
+boolean choiceEnabled = true;
+String defaultValue = "CZ4012340000000012345678";
+
+List<FormFieldConfig> configs = formData.getConfig();
+for (FormFieldConfig config: configs) {
+    if ("operation.bankAccountChoice".equals(config.getId())) {
+        choiceEnabled = config.isEnabled();
+        // You should check the default value against list of available accounts.
+        defaultValue = config.getDefaultValue();
+    }
+}
+Attribute attr = formData.addBankAccountChoice(BANK_ACCOUNT_CHOICE_ID, bankAccounts, choiceEnabled, defaultValue);
+```
+
+### Adding form banners
+
+The example below adds a banner on top of the operation form:
+```java
+formData.addBanner(BannerType.BANNER_WARNING, "banner.warning");
+```
+
+The available banner types are:
+- BANNER_ERROR
+- BANNER_WARNING
+- BANNER_INFO
+
+The second parameter is the localization string with text message of the banner.
+
+### Adding banners before fields
+
+The example below decorates operation form data by adding banner above the `BANK_ACCOUNT_CHOICE` attribute which was previously added:
+```java
+formData.addBannerBeforeField(BannerType.BANNER_WARNING, "banner.invalidAccount", attr);
+```
+
+The available banner types are:
+- BANNER_ERROR
+- BANNER_WARNING
+- BANNER_INFO
+
+The second parameter is the localization string with text message of the banner.
+
+The third parameter is the attribute before which the banner is added.
+
+### Adding headings
+The example below shows how to add a heading attribute:
+
+```java
+formData.addHeading("operation.heading1", "operation.headingTop", ValueFormatType.LOCALIZED_TEXT);
+```
+
+The parameters are:
+* ID of the heading attribute (label is not displayed, so it is not localized)
+* Localization ID of message for heading
+* LOCALIZED_TEXT is the value format type for text localization by chosen language
+
+For non-localized version of heading you can use:
+```java
+formData.addHeading("operation.heading1", "Payment");
+```
+
+### Adding party information
+The example below shows how to add information about a third party:
+```java
+// Add information about 3rd party
+PartyInfo partyInfo = new PartyInfo();
+partyInfo.setName("Tesco PLC");
+partyInfo.setLogoUrl("https://www.tescoplc.com/media/474818/plc_image_logo.png?anchor=center&mode=crop&width=820&height=462&rnd=131722809190000000");
+partyInfo.setDescription("British groceries and general merchandise retailer");
+partyInfo.setWebsiteUrl("https://www.tescoplc.com");
+formData.addPartyInfo("operation.partyInfo", partyInfo);
+```
+
+In order to add party information before an existing field instead of appending it after last field, use the `addPartyInfoBeforeField()` method.
+
+### Adding application context
+
+The example below specifies application context for an operation. The application context is used in `CONSENT` step to generate the consent form. 
+```java
+ApplicationContext applicationContext = new ApplicationContext();
+applicationContext.setId("DEMO");
+applicationContext.setName("Demo application");
+applicationContext.setDescription("Web Flow demo application");
+applicationContext.getOriginalScopes().add("aisp");
+applicationContext.getExtras().put("applicationOwner", "Wultra");
+```
+
+Note that the `extras` is a Map which can be used for adding other key-value items required for the consent form. Use the create `ApplicationContext`
+instance when creating the operation.
+
+### Operation Form Data JSON
+
+When creating operations using Next Step API, you can specify operation form data using JSON instead of using the Java API.
+
+Note: `label` and `formattedValue` fields in examples below are always null, because these values are used internally:
+- `label` is localized by taking the `id` and localizing it into current language
+- `formattedValues` is constructed using logic based on `valueFormatType` and field value
+
+`AMOUNT`:
+```json
+        {
+          "type": "AMOUNT",
+          "id": "operation.amount",
+          "label": null,
+          "valueFormatType": "AMOUNT",
+          "formattedValues": {},
+          "amount": 100,
+          "currency": "CZK",
+          "currencyId": "operation.currency"
+        }
+```
+
+Remarks:
+- Always use `AMOUNT` as `valueFormatType`
+- The `amount` value can use decimal point
+- Use ISO format of `currency`, the value is localized using message resources (e.g. `currency.CZK.name`)
+- The `currencyId` value is used to determine localization ID for the word "currency"
+
+`KEY_VALUE`:
+```json
+        {
+          "type": "KEY_VALUE",
+          "id": "operation.account",
+          "label": null,
+          "valueFormatType": "ACCOUNT",
+          "formattedValues": {},
+          "value": "238400856/0300"
+        }
+```
+Remarks:
+- Supported value format types which influence the `formattedValue`: 
+  - `TEXT` - non-localized text (as is)
+  - `LOCALIZED_TEXT` - localized text (using message resources)
+  - `DATE` - date formatted in operation locale
+  - `NUMBER` - generic number formatted in operation locale
+  - `AMOUNT` - monetary amount formatted in operation locale
+  - `ACCOUNT` - account value (not formatted because the syntax may differ greatly)
+
+`NOTE`:
+```json
+        {
+          "type": "NOTE",
+          "id": "operation.note",
+          "label": null,
+          "valueFormatType": "TEXT",
+          "formattedValues": {},
+          "note": "Utility Bill Payment - 05/2019"
+        }
+```
+
+Remarks:
+- The `note` string is not localized, it is taken "as is".
+
+`HEADING`:
+```json
+        {
+          "type": "HEADING",
+          "id": "operation.heading1",
+          "label": null,
+          "valueFormatType": "TEXT",
+          "formattedValues": {},
+          "value": "Heading"
+        }
+```
+
+Remarks:
+- The `label` is ignored, the `HEADING` field uses only a value.
+- The `value` is formatted using given `valueFormatType` (same value format types as in `KEY_VALUE`).
+
+`BANNER`:
+```json
+        {
+          "type": "BANNER",
+          "id": "banner.error",
+          "label": null,
+          "message": null,
+          "bannerType": "BANNER_ERROR"
+        }
+```
+
+Remarks:
+- The `label` is ignored, the `BANNER` field uses only a value.
+- The banner message is taken from the `id` field by localizing message resource with such ID.
+- Supported banner types:
+   - BANNER_ERROR
+   - BANNER_WARNING
+   - BANNER_INFO
+
+`PARTY_INFO`:
+```json
+        {
+          "type": "PARTY_INFO",
+          "id": "operation.partyInfo",
+          "label": null,
+          "partyInfo": {
+            "logoUrl": "https://itesco.cz/img/logo/logo.svg",
+            "name": "Tesco",
+            "description": "Objevte více příběhů psaných s chutí",
+            "websiteUrl": "https://itesco.cz/hello/vse-o-jidle/pribehy-psane-s-chuti/clanek/tomovy-burgery-pro-zapalene-fanousky/15012"
+          }
+        }
+```
+
+Remarks:
+- The value is structured and it is not localized.
diff --git a/docs/_Sidebar.md b/docs/_Sidebar.md
index fac9c4293..3d4864864 100644
--- a/docs/_Sidebar.md
+++ b/docs/_Sidebar.md
@@ -9,6 +9,11 @@
 **Mobile Token**
 
 - [Operation Extensions](./Operation-Extensions.md)
+- [Operation Data](./Operation-Data.md)
+- [Operation Form Data](./Operation-Form-Data.md)
+- [Offline Signatures](./Offline-Signatures-QR-Code.md)
+- [Mobile Token Operations API](./Mobile-Token-Operations-API.md)
+- [Mobile Push Registration API](./Mobile-Push-Registration-API.md)  
 
 **Implementation Tutorials**
 

From 8c90a2602295b9e325eefd0f3c2acdb4849e3ed1 Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 12:14:51 +0800
Subject: [PATCH 02/16] Convert existing documentation to standard REST API
 documentation format

---
 docs/Enrollment-Server-API.md        | 594 +++++++++++++++++++++++++++
 docs/Mobile-Push-Registration-API.md | 114 -----
 docs/Mobile-Token-Operations-API.md  | 241 -----------
 3 files changed, 594 insertions(+), 355 deletions(-)
 create mode 100644 docs/Enrollment-Server-API.md
 delete mode 100644 docs/Mobile-Push-Registration-API.md
 delete mode 100644 docs/Mobile-Token-Operations-API.md

diff --git a/docs/Enrollment-Server-API.md b/docs/Enrollment-Server-API.md
new file mode 100644
index 000000000..2e00f43fa
--- /dev/null
+++ b/docs/Enrollment-Server-API.md
@@ -0,0 +1,594 @@
+# Enrollment Server API
+<!-- template api -->
+
+Enrollment Server provides a RESTful API used by the Mobile Token application. The API consists of following parts:
+
+- [Operations API](#operations-api)
+- [Push Registration API](#push-registration-api)
+- [Activation Spawn API](#activation-spawn-api)
+- [Message Inbox API](#message-inbox-api)
+
+The generated REST API documentation in deployed Enrollment server, and it includes standard PowerAuth RESTful API:
+
+```
+http[s]://[host]:[port]/enrollment-server/swagger-ui.html
+```
+
+Following endpoints are published in Enrollment Server RESTful API:
+
+<!-- begin remove -->
+## Methods
+
+##### **Request**
+- Headers:
+    - `Content-Type: application/json`
+- required extensive details stored in `requestObject`
+
+#### **Response**
+- Status Code: `200`
+- Headers:
+    - `Content-Type: application/json`
+- extensive details stored in `responseObject`
+
+#### Operations API
+
+- `POST` [/api/auth/token/app/operation/list](#get-pending-operations) - List pending Mobile Token operations
+- `POST` [/api/auth/token/app/operation/history](#get-operations-history) - Get history of Mobile Token operations
+- `POST` [/api/auth/token/app/operation/authorize](#confirm-operation) - Confirm a Mobile Token operation
+- `POST` [/api/auth/token/app/operation/cancel](#reject-operation) - Reject a Mobile Token operation
+
+#### Push Registration API
+
+- `POST` [/api/push/device/register](#register-for-push-messages-signed) - Register a mobile device for push messages with PowerAuth signature
+- `POST` [/api/push/device/register/token](#register-for-push-messages-token) - Register a mobile device for push messages with PowerAuth token
+
+#### Activation Spawn API
+
+- `POST` [/api/activation/code](#activation-spawn) - Handle request for activation code in activation spawn
+
+#### Message Inbox API
+
+- `POST` [/api/inbox/count](#inbox-count) - Get inbox message count
+- `POST` [/api/inbox/message/list](#inbox-message-list) - Get inbox message list
+- `POST` [/api/inbox/message/detail](#inbox-message-detail) - Get inbox message detail
+- `POST` [/api/inbox/message/read](#inbox-message-read) - Read an inbox message
+- `POST` [/api/inbox/message/read-all](#inbox-message-read-all) - Read all inbox messages
+<!-- end -->
+
+### Error Handling
+
+Enrollment Server uses following format for error response body, accompanied by an appropriate HTTP status code. Besides the HTTP error codes that application server may return regardless of server application (such as 404 when resource is not found or 503 when server is down), following status codes may be returned:
+
+| Status | HTTP Code | Description |
+|--------|-----------|-------------|
+| OK     | 200       | No issue    |
+| ERROR  | 400       | Issue with a request format, or issue of the business logic |
+| ERROR  | 401       | Unauthorized |
+
+All error responses that are produced by the Enrollment Server have the following body:
+
+```json
+
+{
+  "status": "ERROR",
+  "responseObject": {
+    "code": "ERROR_GENERIC",
+    "message": "An error message"
+  }
+}
+```
+
+- `status` - `OK`, `ERROR`
+- `code` - `ERROR_GENERIC`
+- `message` - Message that describes certain error.
+
+## Mobile Token API for Operations
+
+Mobile token API provides access to operations.
+
+## Mobile API Error Codes
+
+List of error codes in Mobile Token API:
+
+| Code | Description | HTTP Status Code |
+|---|---|---|
+| `INVALID_REQUEST` | Invalid request sent - missing request object in request | 400 |
+| `INVALID_ACTIVATION` | Activation is not valid (it is different from configured activation). Return this error in case the activation does not exist, or in case the activation is not allowed to perform the action (for example, user did not allow operation approvals on such device). | 400 |
+| `POWERAUTH_AUTH_FAIL` | PowerAuth authentication failed | 401 |
+| `OPERATION_ALREADY_FINISHED` | Operation is already finished | 400 |
+| `OPERATION_ALREADY_FAILED` | Operation is already failed | 400 |
+| `OPERATION_ALREADY_CANCELED` | Operation is already canceled | 400 |
+| `OPERATION_EXPIRED` | Operation is expired | 400 |
+
+## Localization
+
+In order to get a correctly localized response, use the `Accept-Language` HTTP header in your request.
+
+<!-- begin api POST /api/auth/token/app/operation/list -->
+### Get Pending Operations
+
+Get the list with all operations that are pending confirmation.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/auth/token/app/operation/list</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+    - `Content-Type: application/json`
+    - `Accept-Language: en-US`
+    - `X-PowerAuth-Authorization: ...`
+
+```json
+{}
+```
+
+#### Response 200
+
+```json
+{
+  "status": "OK",
+  "responseObject": [
+    {
+      "id": "7e0ba60f-bf22-4ff5-b999-2733784e5eaa",
+      "name": "authorize_payment",
+      "data": "A1*A100CZK*Q238400856/0300**D20190629*NUtility Bill Payment - 05/2019",
+      "status": "PENDING",
+      "operationCreated": "2018-07-02T14:43:13+0000",
+      "operationExpires": "2018-07-02T14:48:17+0000",
+      "allowedSignatureType": {
+        "type": "2FA",
+        "variants": [
+          "possession_knowledge",
+          "possession_biometry"
+        ]
+      },
+      "formData": {
+        "title": "Confirm Payment",
+        "message": "Hello,\nplease confirm following payment:",
+        "attributes": [
+          {
+            "type": "HEADING",
+            "id": "operation.heading",
+            "label": "Utility Payment"
+          },
+          {
+            "type": "AMOUNT",
+            "id": "operation.amount",
+            "label": "Amount",
+            "amount": 100,
+            "currency": "CZK",
+            "amountFormatted": "100,00",
+            "currencyFormatted": "Kč"
+          },
+          {
+            "type": "KEY_VALUE",
+            "id": "operation.account",
+            "label": "To Account",
+            "value": "238400856/0300"
+          },
+          {
+            "type": "KEY_VALUE",
+            "id": "operation.dueDate",
+            "label": "Due Date",
+            "value": "Jun 29, 2019"
+          },
+          {
+            "type": "NOTE",
+            "id": "operation.note",
+            "label": "Note",
+            "note": "Utility Bill Payment - 05/2019"
+          },
+          {
+            "type": "PARTY_INFO",
+            "id": "operation.partyInfo",
+            "label": "Application",
+            "partyInfo": {
+              "logoUrl": "https://itesco.cz/img/logo/logo.svg",
+              "name": "Tesco",
+              "description": "Find out more about Tesco...",
+              "websiteUrl": "https://itesco.cz/hello"
+            }
+          }
+        ]
+      }
+    }
+  ]
+}
+```
+<!-- end -->
+
+<!-- begin api POST /api/auth/token/app/operation/history -->
+### Get Operations History
+
+Get the list of confirmed or rejected Mobile Token operations. 
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/auth/token/app/operation/history</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `Accept-Language: en-US`
+  - `X-PowerAuth-Authorization: ...`
+
+```json
+{}
+```
+
+#### Response 200
+
+```json
+{
+  "status": "OK",
+  "responseObject": [
+    {
+      "id": "7e0ba60f-bf22-4ff5-b999-2733784e5eaa",
+      "name": "authorize_payment",
+      "data": "A1*A100CZK*Q238400856/0300**D20190629*NUtility Bill Payment - 05/2019",
+      "status": "APPROVED",
+      "operationCreated": "2018-07-02T14:43:13+0000",
+      "operationExpires": "2018-07-02T14:48:17+0000",
+      "allowedSignatureType": {
+        "type": "2FA",
+        "variants": [
+          "possession_knowledge",
+          "possession_biometry"
+        ]
+      },
+      "formData": {
+        "title": "Confirm Payment",
+        "message": "Hello,\nplease confirm following payment:",
+        "attributes": [
+          {
+            "type": "HEADING",
+            "id": "operation.heading",
+            "label": "Utility Payment"
+          },
+          {
+            "type": "AMOUNT",
+            "id": "operation.amount",
+            "label": "Amount",
+            "amount": 100,
+            "currency": "CZK",
+            "amountFormatted": "100,00",
+            "currencyFormatted": "Kč"
+          },
+          {
+            "type": "KEY_VALUE",
+            "id": "operation.account",
+            "label": "To Account",
+            "value": "238400856/0300"
+          },
+          {
+            "type": "KEY_VALUE",
+            "id": "operation.dueDate",
+            "label": "Due Date",
+            "value": "Jun 29, 2019"
+          },
+          {
+            "type": "NOTE",
+            "id": "operation.note",
+            "label": "Note",
+            "note": "Utility Bill Payment - 05/2019"
+          },
+          {
+            "type": "PARTY_INFO",
+            "id": "operation.partyInfo",
+            "label": "Application",
+            "partyInfo": {
+              "logoUrl": "https://itesco.cz/img/logo/logo.svg",
+              "name": "Tesco",
+              "description": "Find out more about Tesco...",
+              "websiteUrl": "https://itesco.cz/hello"
+            }
+          }
+        ]
+      }
+    }
+  ]
+}
+```
+<!-- end -->
+
+<!-- begin api POST /api/auth/token/app/operation/authorize -->
+### Confirm Operation
+
+Confirms an operation with given ID and data. This endpoint requires a signature of a type specified by the operation.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/auth/token/app/operation/authorize</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `X-PowerAuth-Authorization: ...`
+
+```json
+{
+  "requestObject": {
+    "id": "3699a9c0-45f0-458d-84bc-5bde7ec384f7",
+    "data": "A1*A100CZK*Q238400856\/0300**D20190629*NUtility Bill Payment - 05\/2019"
+  }
+}
+```
+
+#### Response 200
+
+```json
+{
+  "status": "OK"
+}
+```
+<!-- end -->
+
+<!-- begin api POST /api/auth/token/app/operation/cancel -->
+### Reject Operation
+
+Reject an operation with given ID, with a provided reason.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/auth/token/app/operation/cancel</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `X-PowerAuth-Authorization: ...`
+
+```json
+{
+  "requestObject": {
+    "id": "352d6cfa-b8d7-4366-af1f-c99b071b4dc4",
+    "reason": "INCORRECT_DATA"
+  }
+}
+```
+
+#### Response 200
+
+```json
+{
+  "status": "OK"
+}
+```
+<!-- end -->
+
+## Enumerations
+
+### Form Attribute Types
+
+| Type | Description |
+|---|---|
+| `AMOUNT` | Form field representing an amount with currency. |
+| `KEY_VALUE` | Form field representing a key value item, where items are displayed next to each other. This realistically impose limitation on value length - it should fit into the single line. |
+| `NOTE` | Form field representing a generic text note, where label is displayed above the note. As a result, note can be of an arbitrary length and can be multi-line. |
+| `HEADING` | Form field representing a heading, where label is displayed as the heading text. |
+| `PARTY_INFO` | Form field representing a structured object with information about a third party. |
+
+### Operation Rejection Reasons
+
+| Type | Description |
+|---|---|
+| `UNKNOWN` | User decided not to tell us the operation rejection reason. |
+| `INCORRECT_DATA` | User claims incorrect data was presented in mToken app. |
+| `UNEXPECTED_OPERATION` | User claims he/she did not expect any operation. |
+
+### Allowed Signature Types
+
+| Type | Description |
+|---|---|
+| `1FA` | One-factor signature - user just has to tap "Confirm" button to confirm it. |
+| `2FA` | Two-factor signature - user needs to use either password of biometry as addition to possession factor. The `variants` key then determines what signature type is allowed for the given operation. |
+| `ECDSA` | ECDSA signature with device private key. |
+
+
+#@ Mobile Push Registration API
+
+In order to register mobile device to the push notifications, following endpoints are published.
+
+<!-- begin api POST /api/push/device/register -->
+### Register for Push Messages (Signed)
+
+Registers a device to push notifications. Authorization is done using PowerAuth signature.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/push/device/register</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `X-PowerAuth-Authorization: ...`
+
+```json
+{
+  "requestObject": {
+    "platform": "ios",
+    "token": "10de0b9c-791f-4e9f-93c4-e2203951c307"
+  }
+}
+```
+
+Supported platforms:
+- `ios`
+- `android`
+
+#### Response 200
+
+```json
+{
+  "status": "OK"
+}
+```
+
+#### Response 400
+
+```json
+{
+    "status": "ERROR",
+    "responseObject": {
+        "code": "PUSH_REGISTRATION_FAILED",
+        "message": "Push registration failed in Mobile Token API component."
+    }
+}
+```
+
+Possible error codes:
+- `PUSH_REGISTRATION_FAILED` - returned when Push Server returns error during registration.
+- `INVALID_REQUEST` - returned when request object is invalid.
+- `INVALID_ACTIVATION` - returned when application or activation is invalid.
+
+#### Response 401
+
+Returned when PowerAuth authentication fails.
+
+```json
+{
+  "status": "ERROR",
+  "responseObject": {
+    "code": "POWERAUTH_AUTH_FAIL",
+    "message": "Unable to verify device registration"
+  }
+}
+```
+
+<!-- end -->
+
+<!-- begin api POST /api/push/device/register/token -->
+### Register for Push Messages (Token)
+
+Registers a device to push notifications. Authorization is done using PowerAuth token.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/push/device/register/token</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `X-PowerAuth-Token: ...`
+
+```json
+{
+  "requestObject": {
+    "platform": "ios",
+    "token": "10de0b9c-791f-4e9f-93c4-e2203951c307"
+  }
+}
+```
+
+Supported platforms:
+- `ios`
+- `android`
+
+#### Response 200
+
+```json
+{
+  "status": "OK"
+}
+```
+
+#### Response 400
+
+```json
+{
+    "status": "ERROR",
+    "responseObject": {
+        "code": "PUSH_REGISTRATION_FAILED",
+        "message": "Push registration failed in Mobile Token API component."
+    }
+}
+```
+
+Possible error codes:
+- `PUSH_REGISTRATION_FAILED` - returned when Push Server returns error during registration.
+- `INVALID_REQUEST` - returned when request object is invalid.
+- `INVALID_ACTIVATION` - returned when application or activation is invalid.
+
+#### Response 401
+
+Returned when PowerAuth authentication fails.
+
+```json
+{
+  "status": "ERROR",
+  "responseObject": {
+    "code": "POWERAUTH_AUTH_FAIL",
+    "message": "Unable to verify device registration"
+  }
+}
+```
+
+<!-- end -->
+
+<!-- end -->
diff --git a/docs/Mobile-Push-Registration-API.md b/docs/Mobile-Push-Registration-API.md
deleted file mode 100644
index 4fdaabb43..000000000
--- a/docs/Mobile-Push-Registration-API.md
+++ /dev/null
@@ -1,114 +0,0 @@
-# Mobile Push Registration API
-
-In order to register mobile device to the push notifications, following endpoints are published.
-
-## Endpoints
-
-### Register for Push Notifications
-
-Registers a device to push notifications.
-
-<table>
-    <tr>
-        <td>Method</td>
-        <td><code>POST</code></td>
-    </tr>
-    <tr>
-        <td>Resource URI</td>
-        <td><code>/api/push/device/register/token</code></td>
-    </tr>
-</table>
-
-#### Request
-
-- Headers:
-    - `Content-Type: application/json`
-    - `X-PowerAuth-Token: ...`
-
-```json
-{
-  "requestObject": {
-      "platform": "ios",
-      "token": "10de0b9c-791f-4e9f-93c4-e2203951c307"
-  }
-}
-```
-
-Supported platforms:
-- `ios`
-- `android`
-
-#### Success Response
-- Status Code: `200`
-- Headers:
-    - `Content-Type: application/json`
-
-```json
-{
-  "status": "OK"
-}
-```
-
-#### Error Response - Push Registration Failed
-- Returned when Push Server returns error during registration.
-- Status Code: `400`
-- Headers:
-    - `Content-Type: application/json`
-
-```json
-{
-    "status": "ERROR",
-    "responseObject": {
-        "code": "PUSH_REGISTRATION_FAILED",
-        "message": "Push registration failed in Mobile Token API component."
-    }
-}
-```
-
-#### Error Response - PowerAuth Authentication Failed
-- Returned when PowerAuth authentication fails.
-- Status Code: `401`
-- Headers:
-    - `Content-Type: application/json`
-
-```json
-{
-    "status": "ERROR",
-    "responseObject": {
-        "code": "POWERAUTH_AUTH_FAIL",
-        "message": "Unable to verify device registration"
-    }
-}
-```
-
-#### Error Response - Invalid Request Object
-- Returned when request object is invalid.
-- Status Code: `400`
-- Headers:
-    - `Content-Type: application/json`
-
-```json
-{
-    "status": "ERROR",
-    "responseObject": {
-        "code": "INVALID_REQUEST",
-        "message": "Invalid request object sent to Mobile Token API component."
-    }
-}
-```
-
-#### Error Response - Invalid Activation
-- Returned when application or activation is invalid.
-- Status Code: `400`
-- Headers:
-    - `Content-Type: application/json`
-
-```json
-{
-    "status": "ERROR",
-    "responseObject": {
-        "code": "INVALID_ACTIVATION",
-        "message": "Invalid activation found in Mobile Token API component."
-    }
-}
-```
diff --git a/docs/Mobile-Token-Operations-API.md b/docs/Mobile-Token-Operations-API.md
deleted file mode 100644
index f26d93414..000000000
--- a/docs/Mobile-Token-Operations-API.md
+++ /dev/null
@@ -1,241 +0,0 @@
-# Mobile Token API for Operations
-
-Mobile token API provides access to operations.
-
-The generated REST API documentation in deployed Enrollment server, and it includes standard PowerAuth RESTful API:
-
-```
-http[s]://[host]:[port]/enrollment-server/swagger-ui.html
-```
-
-## Mobile API Error Codes
-
-List of error codes in Mobile Token API:
-
-| Code | Description | HTTP Status Code |
-|---|---|---|
-| `INVALID_REQUEST` | Invalid request sent - missing request object in request | 400 |
-| `INVALID_ACTIVATION` | Activation is not valid (it is different from configured activation). Return this error in case the activation does not exist, or in case the activation is not allowed to perform the action (for example, user did not allow operation approvals on such device). | 400 |
-| `POWERAUTH_AUTH_FAIL` | PowerAuth authentication failed | 401 |
-| `OPERATION_ALREADY_FINISHED` | Operation is already finished | 400 |
-| `OPERATION_ALREADY_FAILED` | Operation is already failed | 400 |
-| `OPERATION_ALREADY_CANCELED` | Operation is already canceled | 400 |
-| `OPERATION_EXPIRED` | Operation is expired | 400 |
-
-## Localization
-
-In order to get a correctly localized response, please use the `Accept-Language` HTTP header in your request.
-
-## Mobile Token API Endpoints
-
-### Get Pending Operations
-
-Get the list with all operations that are pending confirmation.
-
-<table>
-    <tr>
-        <td>Method</td>
-        <td><code>POST</code></td>
-    </tr>
-    <tr>
-        <td>Resource URI</td>
-        <td><code>/api/auth/token/app/operation/list</code></td>
-    </tr>
-</table>
-
-#### Request
-
-- Headers:
-    - `Content-Type: application/json`
-    - `Accept-Language: en-US`
-    - `X-PowerAuth-Token: ...`
-
-```json
-{}
-```
-
-#### Response
-- Status Code: `200`
-- Headers:
-    - `Content-Type: application/json`
-
-```json
-{
-  "status": "OK",
-  "responseObject": [
-    {
-      "id": "7e0ba60f-bf22-4ff5-b999-2733784e5eaa",
-      "name": "authorize_payment",
-      "data": "A1*A100CZK*Q238400856/0300**D20190629*NUtility Bill Payment - 05/2019",
-      "operationCreated": "2018-07-02T14:43:13+0000",
-      "operationExpires": "2018-07-02T14:48:17+0000",
-      "allowedSignatureType": {
-        "type": "2FA",
-        "variants": [
-          "possession_knowledge",
-          "possession_biometry"
-        ]
-      },
-      "formData": {
-        "title": "Confirm Payment",
-        "message": "Hello,\nplease confirm following payment:",
-        "attributes": [
-          {
-            "type": "HEADING",
-            "id": "operation.heading",
-            "label": "Utility Payment"
-          },
-          {
-            "type": "AMOUNT",
-            "id": "operation.amount",
-            "label": "Amount",
-            "amount": 100,
-            "currency": "CZK",
-            "amountFormatted": "100,00",
-            "currencyFormatted": "Kč"
-          },
-          {
-            "type": "KEY_VALUE",
-            "id": "operation.account",
-            "label": "To Account",
-            "value": "238400856/0300"
-          },
-          {
-            "type": "KEY_VALUE",
-            "id": "operation.dueDate",
-            "label": "Due Date",
-            "value": "Jun 29, 2019"
-          },
-          {
-            "type": "NOTE",
-            "id": "operation.note",
-            "label": "Note",
-            "note": "Utility Bill Payment - 05/2019"
-          },
-          {
-            "type": "PARTY_INFO",
-            "id": "operation.partyInfo",
-            "label": "Application",
-            "partyInfo": {
-              "logoUrl": "https://itesco.cz/img/logo/logo.svg",
-              "name": "Tesco",
-              "description": "Find out more about Tesco...",
-              "websiteUrl": "https://itesco.cz/hello"
-            }
-          }
-        ]
-      }
-    }
-  ]
-}
-```
-
-### Confirm Operation
-
-Confirms an operation with given ID and data. This endpoint requires a signature of a type specified by the operation.
-
-<table>
-    <tr>
-        <td>Method</td>
-        <td><code>POST</code></td>
-    </tr>
-    <tr>
-        <td>Resource URI</td>
-        <td><code>/api/auth/token/app/operation/authorize</code></td>
-    </tr>
-</table>
-
-#### Request
-
-- Headers:
-    - `Content-Type: application/json`
-    - `X-PowerAuth-Authorization: ...`
-
-```json
-{
-  "requestObject": {
-    "id": "3699a9c0-45f0-458d-84bc-5bde7ec384f7",
-    "data": "A1*A100CZK*Q238400856\/0300**D20190629*NUtility Bill Payment - 05\/2019"
-  }
-}
-```
-
-#### Response
-- Status Code: `200`
-- Headers:
-    - `Content-Type: application/json`
-
-```json
-{
-  "status": "OK"
-}
-```
-
-### Reject Operation
-
-Reject an operation with given ID, with a provided reason.
-
-<table>
-    <tr>
-        <td>Method</td>
-        <td><code>POST</code></td>
-    </tr>
-    <tr>
-        <td>Resource URI</td>
-        <td><code>/api/auth/token/app/operation/cancel</code></td>
-    </tr>
-</table>
-
-#### Request
-
-- Headers:
-    - `Content-Type: application/json`
-    - `X-PowerAuth-Authorization: ...`
-
-```json
-{
-  "requestObject": {
-    "id": "352d6cfa-b8d7-4366-af1f-c99b071b4dc4",
-    "reason": "INCORRECT_DATA"
-  }
-}
-```
-
-#### Response
-- Status Code: `200`
-- Headers:
-    - `Content-Type: application/json`
-
-```json
-{
-  "status": "OK"
-}
-```
-
-## Enumerations
-
-### Form Attribute Types
-
-| Type | Description |
-|---|---|
-| `AMOUNT` | Form field representing an amount with currency. |
-| `KEY_VALUE` | Form field representing a key value item, where items are displayed next to each other. This realistically impose limitation on value length - it should fit into the single line. |
-| `NOTE` | Form field representing a generic text note, where label is displayed above the note. As a result, note can be of an arbitrary length and can be multi-line. |
-| `HEADING` | Form field representing a heading, where label is displayed as the heading text. |
-| `PARTY_INFO` | Form field representing a structured object with information about a third party. |
-
-### Operation Rejection Reasons
-
-| Type | Description |
-|---|---|
-| `UNKNOWN` | User decided not to tell us the operation rejection reason. |
-| `INCORRECT_DATA` | User claims incorrect data was presented in mToken app. |
-| `UNEXPECTED_OPERATION` | User claims he/she did not expect any operation. |
-
-### Allowed Signature Types
-
-| Type | Description |
-|---|---|
-| `1FA` | One-factor signature - user just has to tap "Confirm" button to confirm it. |
-| `2FA` | Two-factor signature - user needs to use either password of biometry as addition to possession factor. The `variants` key then determines what signature type is allowed for the given operation. |
-| `ECDSA` | ECDSA signature with device private key. |

From 9702e774bcc5adf057486f4ad2c9e8e780f0f816 Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 12:59:17 +0800
Subject: [PATCH 03/16] Add activation spawn documentation

---
 docs/Enrollment-Server-API.md | 51 +++++++++++++++++++++++++++++++++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/docs/Enrollment-Server-API.md b/docs/Enrollment-Server-API.md
index 2e00f43fa..eb51620ba 100644
--- a/docs/Enrollment-Server-API.md
+++ b/docs/Enrollment-Server-API.md
@@ -44,7 +44,7 @@ Following endpoints are published in Enrollment Server RESTful API:
 
 #### Activation Spawn API
 
-- `POST` [/api/activation/code](#activation-spawn) - Handle request for activation code in activation spawn
+- `POST` [/api/activation/code](#activation-code) - Handle request for activation code in activation spawn
 
 #### Message Inbox API
 
@@ -82,6 +82,7 @@ All error responses that are produced by the Enrollment Server have the followin
 - `code` - `ERROR_GENERIC`
 - `message` - Message that describes certain error.
 
+
 ## Mobile Token API for Operations
 
 Mobile token API provides access to operations.
@@ -429,7 +430,7 @@ Reject an operation with given ID, with a provided reason.
 | `ECDSA` | ECDSA signature with device private key. |
 
 
-#@ Mobile Push Registration API
+## Mobile Push Registration API
 
 In order to register mobile device to the push notifications, following endpoints are published.
 
@@ -591,4 +592,50 @@ Returned when PowerAuth authentication fails.
 
 <!-- end -->
 
+## Activation Spawn
+
+Activation Spawn API contains a single endpoint which is used for requesting the activation code.
+
+<!-- begin api POST /api/activation/code -->
+### Activation Code
+
+Handle a request for activation code in activation spawn.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/activation/code</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `X-PowerAuth-Authorization: ...`
+
+```json
+{
+  "requestObject": {
+    "applicationId": "app1",
+    "otp": "12345678"
+  }
+}
+```
+
+#### Response 200
+
+```json
+{
+  "status": "OK"
+}
+```
+
 <!-- end -->

From 7933db5fc27770be36c6fca7d69ac3df38677565 Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 13:30:48 +0800
Subject: [PATCH 04/16] Document message inbox API

---
 docs/Enrollment-Server-API.md | 250 +++++++++++++++++++++++++++++++++-
 1 file changed, 245 insertions(+), 5 deletions(-)

diff --git a/docs/Enrollment-Server-API.md b/docs/Enrollment-Server-API.md
index eb51620ba..4cf7431fe 100644
--- a/docs/Enrollment-Server-API.md
+++ b/docs/Enrollment-Server-API.md
@@ -48,11 +48,11 @@ Following endpoints are published in Enrollment Server RESTful API:
 
 #### Message Inbox API
 
-- `POST` [/api/inbox/count](#inbox-count) - Get inbox message count
-- `POST` [/api/inbox/message/list](#inbox-message-list) - Get inbox message list
-- `POST` [/api/inbox/message/detail](#inbox-message-detail) - Get inbox message detail
-- `POST` [/api/inbox/message/read](#inbox-message-read) - Read an inbox message
-- `POST` [/api/inbox/message/read-all](#inbox-message-read-all) - Read all inbox messages
+- `POST` [/api/inbox/count](#inbox-count) - Get Inbox message count
+- `POST` [/api/inbox/message/list](#inbox-message-list) - Get Inbox message list
+- `POST` [/api/inbox/message/detail](#inbox-message-detail) - Get Inbox message detail
+- `POST` [/api/inbox/message/read](#inbox-message-read) - Read an Inbox message
+- `POST` [/api/inbox/message/read-all](#inbox-message-read-all) - Read all Inbox messages
 <!-- end -->
 
 ### Error Handling
@@ -639,3 +639,243 @@ Handle a request for activation code in activation spawn.
 ```
 
 <!-- end -->
+
+## Message Inbox
+
+Message Inbox API provides endpoints for managing the message inbox.
+
+<!-- begin api POST /api/inbox/count -->
+### Inbox Message Count
+
+Get count of unread messages in Inbox.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/inbox/count</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `X-PowerAuth-Token: ...`
+
+```json
+{}
+```
+
+#### Response 200
+
+```json
+{
+  "status": "OK",
+  "responseObject": {
+    "countUnread": 10
+  }
+}
+```
+
+<!-- end -->
+
+<!-- begin api POST /api/inbox/message/list -->
+### Inbox Message List
+
+Get messages in Inbox.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/inbox/message/list</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `X-PowerAuth-Token: ...`
+
+```json
+{
+  "requestObject": {
+    "page": 0,
+    "size": 10,
+    "onlyUnread": false
+  }
+}
+```
+
+#### Response 200
+
+```json
+{
+  "status": "OK",
+  "responseObject": [
+    {
+      "id": "ae641389-d37a-4425-bd14-41c29484596f",
+      "type": "text",
+      "subject": "Example subject",
+      "summary": "Example summary",
+      "read": false,
+      "timestampCreated": "2022-08-25T22:34:58.702+00:00"
+    }
+  ]
+}
+```
+
+<!-- end -->
+
+<!-- begin api POST /api/inbox/message/detail -->
+### Inbox Message Detail
+
+Get detail of a message in Inbox.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/inbox/message/detail</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `X-PowerAuth-Token: ...`
+
+```json
+{
+  "requestObject": {
+    "id": "ae641389-d37a-4425-bd14-41c29484596f"
+  }
+}
+```
+
+#### Response 200
+
+```json
+{
+  "status": "OK",
+  "responseObject": [
+    {
+      "id": "ae641389-d37a-4425-bd14-41c29484596f",
+      "type": "text",
+      "subject": "Example subject",
+      "summary": "Example summary",
+      "body": "Example message body",
+      "read": false,
+      "timestampCreated": "2022-08-25T22:34:58.702+00:00"
+    }
+  ]
+}
+```
+
+<!-- end -->
+
+<!-- begin api POST /api/inbox/message/read -->
+### Inbox Message Read
+
+Mark a message in inbox as read.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/inbox/message/read</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `X-PowerAuth-Token: ...`
+
+```json
+{
+  "requestObject": {
+    "id": "ae641389-d37a-4425-bd14-41c29484596f"
+  }
+}
+```
+
+#### Response 200
+
+```json
+{
+  "status": "OK"
+}
+```
+
+<!-- end -->
+
+<!-- begin api POST /api/inbox/message/read-all -->
+### Inbox Message Read All
+
+Mark all messages in inbox as read.
+
+<!-- begin remove -->
+
+<table>
+    <tr>
+        <td>Method</td>
+        <td><code>POST</code></td>
+    </tr>
+    <tr>
+        <td>Resource URI</td>
+        <td><code>/api/inbox/message/read-all</code></td>
+    </tr>
+</table>
+<!-- end -->
+
+#### Request
+
+- Headers:
+  - `Content-Type: application/json`
+  - `X-PowerAuth-Token: ...`
+
+```json
+{}
+```
+
+#### Response 200
+
+```json
+{
+  "status": "OK"
+}
+```
+
+<!-- end -->
+
+<!-- end -->
+

From 541250ddeaeeef795365b637e7001c6ec40e2e9d Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 13:33:13 +0800
Subject: [PATCH 05/16] Update sidebar

---
 docs/{Enrollment-Server-API.md => Mobile-Token-API.md} | 2 +-
 docs/_Sidebar.md                                       | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)
 rename docs/{Enrollment-Server-API.md => Mobile-Token-API.md} (99%)

diff --git a/docs/Enrollment-Server-API.md b/docs/Mobile-Token-API.md
similarity index 99%
rename from docs/Enrollment-Server-API.md
rename to docs/Mobile-Token-API.md
index 4cf7431fe..faf314f33 100644
--- a/docs/Enrollment-Server-API.md
+++ b/docs/Mobile-Token-API.md
@@ -1,4 +1,4 @@
-# Enrollment Server API
+# Mobile Token API
 <!-- template api -->
 
 Enrollment Server provides a RESTful API used by the Mobile Token application. The API consists of following parts:
diff --git a/docs/_Sidebar.md b/docs/_Sidebar.md
index 3d4864864..786efba6b 100644
--- a/docs/_Sidebar.md
+++ b/docs/_Sidebar.md
@@ -12,8 +12,7 @@
 - [Operation Data](./Operation-Data.md)
 - [Operation Form Data](./Operation-Form-Data.md)
 - [Offline Signatures](./Offline-Signatures-QR-Code.md)
-- [Mobile Token Operations API](./Mobile-Token-Operations-API.md)
-- [Mobile Push Registration API](./Mobile-Push-Registration-API.md)  
+- [Mobile Token API](./Mobile-Token-API.md)
 
 **Implementation Tutorials**
 

From f1a1be3c4589f1924c7575e33aed9e67d967f4d7 Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 13:56:36 +0800
Subject: [PATCH 06/16] Remove references to Web Flow

---
 docs/Operation-Form-Data.md | 195 +-----------------------------------
 1 file changed, 1 insertion(+), 194 deletions(-)

diff --git a/docs/Operation-Form-Data.md b/docs/Operation-Form-Data.md
index 7f79a41a2..7351042e0 100644
--- a/docs/Operation-Form-Data.md
+++ b/docs/Operation-Form-Data.md
@@ -1,10 +1,6 @@
 # Customizing Operation Form Data
 
-When creating an operation, you can customize the operation form data. This customization has an effect on how the operation form data is displayed during the operation review step.
-
-The customization should be done by the client which initiates the operation before the authentication process is initiated.
-
-For more information about operation form data see the [Next Step REST API](./Next-Step-Server-REST-API-Reference.md#operation-formdata).
+When creating an operation, you can customize the operation form data. This customization has an effect on how the operation form data is displayed in the Mobile Token application.
 
 ## Standard Operation Form Data Attributes
 
@@ -40,195 +36,6 @@ The value is formatted based on specified format type. The following format type
 - `AMOUNT` - value is formatted as amount with currency using current locale
 - `ACCOUNT` - value is not formatted (reserved for future use)
 
-## Resource Localization
-
-Form data labels are specified using localization key, such as "operation.title". This key is localized using resources. See chapter [Customizing Web Flow Appearance](https://github.com/wultra/powerauth-webflow-customization/blob/develop/docs/Customizing-Web-Flow-Appearance.md) for details about updating resources.
-
-Form data value localization for custom attributes:
-- Form data values are localized in case they use the `LOCALIZED_TEXT` value format type.
-- Currency in `AMOUNT` form data type is localized using message resource: `currency.[currency].name`.
-
-Other form data values are not localized and are displayed as received.
-
-## Resource Translation
-
-Resource translation is process of inserting other form data values into existing values.
-
-Example:
-```
-operation.summary=Hello, please confirm payment {operation.amount} {operation.currency} to account {operation.account}.
-```
-
-Summary is translated into:
-```
-operation.summary=Hello, please confirm payment 100 CZK to account 12345678/0123.
-```
-
-Resource translation is performed on following attribute values:
-- `title`
-- `greeting`
-- `summary`
-
-## Java API for Operation Form Data
-
-See example below:
-```java
-
-// variable definition
-String account = "238400856/0300";
-BigDecimal amount = BigDecimal.valueOf(100);
-String currency = "CZK";
-String note = "Utility Bill Payment - 05/2019";
-String dueDate = "2019-06-29";
-
-// operation form data initialization
-OperationFormData formData = new OperationFormData();
-formData.addTitle("operation.title");
-formData.addGreeting("operation.greeting");
-formData.addSummary("operation.summary");
-formData.addAmount("operation.amount", amount, "operation.currency", currency);
-formData.addKeyValue("operation.account", account, ValueFormatType.ACCOUNT);
-formData.addKeyValue("operation.dueDate", dueDate, ValueFormatType.DATE);
-formData.addNote("operation.note", note, ValueFormatType.TEXT);
-
-// sample operation configuration for bank account choice select
-OperationFormFieldConfig bankAccountConfig = new OperationFormFieldConfig();
-bankAccountConfig.setId("operation.bankAccountChoice");
-bankAccountConfig.setEnabled(false);
-bankAccountConfig.setDefaultValue("CZ4043210000000087654321");
-formData.getConfig().add(bankAccountConfig);
-
-// operation initialization
-final ObjectResponse<CreateOperationResponse> payment = client.createOperation("authorize_payment", data, formData, null, applicationContext);
-session.setAttribute("operationId", payment.getResponseObject().getOperationId());
-```
-
-## Decorating Operation Form Data in Data Adapter
-
-Operation form data can be decorated in Data Adapter by implementing method `decorateFormData`. The additional form attributes appear during the operation review step (after the user was authenticated and operation authorization is required).
-
-### Adding bank account choice
-
-The example below decorates operation form data -- three bank accounts are added to the `BANK_ACCOUNT_CHOICE` attribute:
-```java
-List<BankAccount> bankAccounts = new ArrayList<>();
-
-BankAccount bankAccount1 = new BankAccount();
-bankAccount1.setName("Běžný účet v CZK");
-bankAccount1.setBalance(new BigDecimal("24394.52"));
-bankAccount1.setNumber("12345678/1234");
-bankAccount1.setAccountId("CZ4012340000000012345678");
-bankAccount1.setCurrency("CZK");
-bankAccounts.add(bankAccount1);
-
-BankAccount bankAccount2 = new BankAccount();
-bankAccount2.setName("Spořící účet v CZK");
-bankAccount2.setBalance(new BigDecimal("158121.10"));
-bankAccount2.setNumber("87654321/4321");
-bankAccount2.setAccountId("CZ4043210000000087654321");
-bankAccount2.setCurrency("CZK");
-bankAccounts.add(bankAccount2);
-
-BankAccount bankAccount3 = new BankAccount();
-bankAccount3.setName("Spořící účet v EUR");
-bankAccount3.setBalance(new BigDecimal("1.90"));
-bankAccount3.setNumber("44444444/1111");
-bankAccount3.setAccountId("CZ4011110000000044444444");
-bankAccount3.setCurrency("EUR");
-bankAccount3.setUsableForPayment(false);
-bankAccount3.setUnusableForPaymentReason(dataAdapterI18NService.messageSource().getMessage("operationReview.balanceTooLow", null, LocaleContextHolder.getLocale()));
-bankAccounts.add(bankAccount3);
-
-boolean choiceEnabled = true;
-String defaultValue = "CZ4012340000000012345678";
-
-List<FormFieldConfig> configs = formData.getConfig();
-for (FormFieldConfig config: configs) {
-    if ("operation.bankAccountChoice".equals(config.getId())) {
-        choiceEnabled = config.isEnabled();
-        // You should check the default value against list of available accounts.
-        defaultValue = config.getDefaultValue();
-    }
-}
-Attribute attr = formData.addBankAccountChoice(BANK_ACCOUNT_CHOICE_ID, bankAccounts, choiceEnabled, defaultValue);
-```
-
-### Adding form banners
-
-The example below adds a banner on top of the operation form:
-```java
-formData.addBanner(BannerType.BANNER_WARNING, "banner.warning");
-```
-
-The available banner types are:
-- BANNER_ERROR
-- BANNER_WARNING
-- BANNER_INFO
-
-The second parameter is the localization string with text message of the banner.
-
-### Adding banners before fields
-
-The example below decorates operation form data by adding banner above the `BANK_ACCOUNT_CHOICE` attribute which was previously added:
-```java
-formData.addBannerBeforeField(BannerType.BANNER_WARNING, "banner.invalidAccount", attr);
-```
-
-The available banner types are:
-- BANNER_ERROR
-- BANNER_WARNING
-- BANNER_INFO
-
-The second parameter is the localization string with text message of the banner.
-
-The third parameter is the attribute before which the banner is added.
-
-### Adding headings
-The example below shows how to add a heading attribute:
-
-```java
-formData.addHeading("operation.heading1", "operation.headingTop", ValueFormatType.LOCALIZED_TEXT);
-```
-
-The parameters are:
-* ID of the heading attribute (label is not displayed, so it is not localized)
-* Localization ID of message for heading
-* LOCALIZED_TEXT is the value format type for text localization by chosen language
-
-For non-localized version of heading you can use:
-```java
-formData.addHeading("operation.heading1", "Payment");
-```
-
-### Adding party information
-The example below shows how to add information about a third party:
-```java
-// Add information about 3rd party
-PartyInfo partyInfo = new PartyInfo();
-partyInfo.setName("Tesco PLC");
-partyInfo.setLogoUrl("https://www.tescoplc.com/media/474818/plc_image_logo.png?anchor=center&mode=crop&width=820&height=462&rnd=131722809190000000");
-partyInfo.setDescription("British groceries and general merchandise retailer");
-partyInfo.setWebsiteUrl("https://www.tescoplc.com");
-formData.addPartyInfo("operation.partyInfo", partyInfo);
-```
-
-In order to add party information before an existing field instead of appending it after last field, use the `addPartyInfoBeforeField()` method.
-
-### Adding application context
-
-The example below specifies application context for an operation. The application context is used in `CONSENT` step to generate the consent form. 
-```java
-ApplicationContext applicationContext = new ApplicationContext();
-applicationContext.setId("DEMO");
-applicationContext.setName("Demo application");
-applicationContext.setDescription("Web Flow demo application");
-applicationContext.getOriginalScopes().add("aisp");
-applicationContext.getExtras().put("applicationOwner", "Wultra");
-```
-
-Note that the `extras` is a Map which can be used for adding other key-value items required for the consent form. Use the create `ApplicationContext`
-instance when creating the operation.
-
 ### Operation Form Data JSON
 
 When creating operations using Next Step API, you can specify operation form data using JSON instead of using the Java API.

From 87fd79c5906aa963d3c85f3a5b6a01d77c621667 Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 14:23:35 +0800
Subject: [PATCH 07/16] Reorder sidebar

---
 docs/_Sidebar.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/_Sidebar.md b/docs/_Sidebar.md
index 786efba6b..f1cb671e4 100644
--- a/docs/_Sidebar.md
+++ b/docs/_Sidebar.md
@@ -8,11 +8,11 @@
 
 **Mobile Token**
 
+- [Mobile Token API](./Mobile-Token-API.md)
 - [Operation Extensions](./Operation-Extensions.md)
 - [Operation Data](./Operation-Data.md)
 - [Operation Form Data](./Operation-Form-Data.md)
 - [Offline Signatures](./Offline-Signatures-QR-Code.md)
-- [Mobile Token API](./Mobile-Token-API.md)
 
 **Implementation Tutorials**
 

From f84ee244a6d9e3c4015239478d88b37c861f4692 Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 14:25:33 +0800
Subject: [PATCH 08/16] Fix typo

---
 docs/Mobile-Token-API.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/Mobile-Token-API.md b/docs/Mobile-Token-API.md
index faf314f33..5a2a48094 100644
--- a/docs/Mobile-Token-API.md
+++ b/docs/Mobile-Token-API.md
@@ -33,7 +33,7 @@ Following endpoints are published in Enrollment Server RESTful API:
 #### Operations API
 
 - `POST` [/api/auth/token/app/operation/list](#get-pending-operations) - List pending Mobile Token operations
-- `POST` [/api/auth/token/app/operation/history](#get-operations-history) - Get history of Mobile Token operations
+- `POST` [/api/auth/token/app/operation/history](#get-history-of-operations) - Get history of Mobile Token operations
 - `POST` [/api/auth/token/app/operation/authorize](#confirm-operation) - Confirm a Mobile Token operation
 - `POST` [/api/auth/token/app/operation/cancel](#reject-operation) - Reject a Mobile Token operation
 
@@ -211,7 +211,7 @@ Get the list with all operations that are pending confirmation.
 <!-- end -->
 
 <!-- begin api POST /api/auth/token/app/operation/history -->
-### Get Operations History
+### Get History of Operations
 
 Get the list of confirmed or rejected Mobile Token operations. 
 

From 95c0ffc70b468cfcee5f78727d26fd1e27053d25 Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 22:19:55 +0800
Subject: [PATCH 09/16] Fix docucheck links

---
 docs/Configuration-Properties.md            |  2 +-
 docs/Mobile-Token-API.md                    | 19 ++++---------------
 docs/onboarding/Configuration-Properties.md |  2 +-
 3 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/docs/Configuration-Properties.md b/docs/Configuration-Properties.md
index 628203ab7..bfb6bddb9 100644
--- a/docs/Configuration-Properties.md
+++ b/docs/Configuration-Properties.md
@@ -44,4 +44,4 @@ The Enrollment Server uses the following public configuration properties:
 | `powerauth.service.correlation-header.enabled` | `false` | Whether correlation header is enabled |
 | `powerauth.service.correlation-header.name` | `X-Correlation-ID` | Correlation header name |
 | `powerauth.service.correlation-header.value.validation-regexp` | `[a-zA-Z0-9\\-]{8,1024}` | Regular expression for correlation header value validation |
-| `logging.pattern.console` | [See application.properties](https://github.com/wultra/enrollment-server/blob/develop/enrollment-server/src/main/resources/application.properties#L160) | Logging pattern for console which includes the correlation header value |
+| `logging.pattern.console` | [See application.properties](../enrollment-server/src/main/resources/application.properties#L82) | Logging pattern for console which includes the correlation header value |
diff --git a/docs/Mobile-Token-API.md b/docs/Mobile-Token-API.md
index 5a2a48094..375956ada 100644
--- a/docs/Mobile-Token-API.md
+++ b/docs/Mobile-Token-API.md
@@ -19,34 +19,23 @@ Following endpoints are published in Enrollment Server RESTful API:
 <!-- begin remove -->
 ## Methods
 
-##### **Request**
-- Headers:
-    - `Content-Type: application/json`
-- required extensive details stored in `requestObject`
-
-#### **Response**
-- Status Code: `200`
-- Headers:
-    - `Content-Type: application/json`
-- extensive details stored in `responseObject`
-
-#### Operations API
+### Operations API
 
 - `POST` [/api/auth/token/app/operation/list](#get-pending-operations) - List pending Mobile Token operations
 - `POST` [/api/auth/token/app/operation/history](#get-history-of-operations) - Get history of Mobile Token operations
 - `POST` [/api/auth/token/app/operation/authorize](#confirm-operation) - Confirm a Mobile Token operation
 - `POST` [/api/auth/token/app/operation/cancel](#reject-operation) - Reject a Mobile Token operation
 
-#### Push Registration API
+### Push Registration API
 
 - `POST` [/api/push/device/register](#register-for-push-messages-signed) - Register a mobile device for push messages with PowerAuth signature
 - `POST` [/api/push/device/register/token](#register-for-push-messages-token) - Register a mobile device for push messages with PowerAuth token
 
-#### Activation Spawn API
+### Activation Spawn API
 
 - `POST` [/api/activation/code](#activation-code) - Handle request for activation code in activation spawn
 
-#### Message Inbox API
+### Message Inbox API
 
 - `POST` [/api/inbox/count](#inbox-count) - Get Inbox message count
 - `POST` [/api/inbox/message/list](#inbox-message-list) - Get Inbox message list
diff --git a/docs/onboarding/Configuration-Properties.md b/docs/onboarding/Configuration-Properties.md
index 4f3fe11ee..44e482f6b 100644
--- a/docs/onboarding/Configuration-Properties.md
+++ b/docs/onboarding/Configuration-Properties.md
@@ -139,5 +139,5 @@ The Onboarding Server uses the following public configuration properties:
 | `powerauth.service.correlation-header.enabled` | `false` | Whether correlation header is enabled |
 | `powerauth.service.correlation-header.name` | `X-Correlation-ID` | Correlation header name |
 | `powerauth.service.correlation-header.value.validation-regexp` | `[a-zA-Z0-9\\-]{8,1024}` | Regular expression for correlation header value validation |
-| `logging.pattern.console` | [See application.properties](https://github.com/wultra/enrollment-server/blob/develop/enrollment-server/src/main/resources/application.properties#L160) | Logging pattern for console which includes the correlation header value |
+| `logging.pattern.console` | [See application.properties](../../enrollment-server/src/main/resources/application.properties#L82) | Logging pattern for console which includes the correlation header value |
 

From 968ba34885d89804ab5e1f5498ab3c841eeaa7f9 Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 22:23:26 +0800
Subject: [PATCH 10/16] Fix docucheck warnings

---
 docs/Mobile-Token-API.md                    | 7 +------
 docs/onboarding/Configuration-Properties.md | 2 +-
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/docs/Mobile-Token-API.md b/docs/Mobile-Token-API.md
index 375956ada..2eece0cd3 100644
--- a/docs/Mobile-Token-API.md
+++ b/docs/Mobile-Token-API.md
@@ -1,12 +1,7 @@
 # Mobile Token API
 <!-- template api -->
 
-Enrollment Server provides a RESTful API used by the Mobile Token application. The API consists of following parts:
-
-- [Operations API](#operations-api)
-- [Push Registration API](#push-registration-api)
-- [Activation Spawn API](#activation-spawn-api)
-- [Message Inbox API](#message-inbox-api)
+Enrollment Server provides a RESTful API used by the Mobile Token application.
 
 The generated REST API documentation in deployed Enrollment server, and it includes standard PowerAuth RESTful API:
 
diff --git a/docs/onboarding/Configuration-Properties.md b/docs/onboarding/Configuration-Properties.md
index 44e482f6b..257af5287 100644
--- a/docs/onboarding/Configuration-Properties.md
+++ b/docs/onboarding/Configuration-Properties.md
@@ -139,5 +139,5 @@ The Onboarding Server uses the following public configuration properties:
 | `powerauth.service.correlation-header.enabled` | `false` | Whether correlation header is enabled |
 | `powerauth.service.correlation-header.name` | `X-Correlation-ID` | Correlation header name |
 | `powerauth.service.correlation-header.value.validation-regexp` | `[a-zA-Z0-9\\-]{8,1024}` | Regular expression for correlation header value validation |
-| `logging.pattern.console` | [See application.properties](../../enrollment-server/src/main/resources/application.properties#L82) | Logging pattern for console which includes the correlation header value |
+| `logging.pattern.console` | [See application.properties](../../enrollment-server-onboarding/src/main/resources/application.properties#L172) | Logging pattern for console which includes the correlation header value |
 

From 6135f5df0eec447ae40448c5e7501ea38232a6bd Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 22:27:41 +0800
Subject: [PATCH 11/16] Fix docucheck warnings

---
 docs/Mobile-Token-API.md | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/docs/Mobile-Token-API.md b/docs/Mobile-Token-API.md
index 2eece0cd3..33c275b21 100644
--- a/docs/Mobile-Token-API.md
+++ b/docs/Mobile-Token-API.md
@@ -192,7 +192,6 @@ Get the list with all operations that are pending confirmation.
   ]
 }
 ```
-<!-- end -->
 
 <!-- begin api POST /api/auth/token/app/operation/history -->
 ### Get History of Operations
@@ -297,7 +296,6 @@ Get the list of confirmed or rejected Mobile Token operations.
   ]
 }
 ```
-<!-- end -->
 
 <!-- begin api POST /api/auth/token/app/operation/authorize -->
 ### Confirm Operation
@@ -340,7 +338,6 @@ Confirms an operation with given ID and data. This endpoint requires a signature
   "status": "OK"
 }
 ```
-<!-- end -->
 
 <!-- begin api POST /api/auth/token/app/operation/cancel -->
 ### Reject Operation
@@ -495,8 +492,6 @@ Returned when PowerAuth authentication fails.
 }
 ```
 
-<!-- end -->
-
 <!-- begin api POST /api/push/device/register/token -->
 ### Register for Push Messages (Token)
 
@@ -668,8 +663,6 @@ Get count of unread messages in Inbox.
 }
 ```
 
-<!-- end -->
-
 <!-- begin api POST /api/inbox/message/list -->
 ### Inbox Message List
 
@@ -777,8 +770,6 @@ Get detail of a message in Inbox.
 }
 ```
 
-<!-- end -->
-
 <!-- begin api POST /api/inbox/message/read -->
 ### Inbox Message Read
 
@@ -820,8 +811,6 @@ Mark a message in inbox as read.
 }
 ```
 
-<!-- end -->
-
 <!-- begin api POST /api/inbox/message/read-all -->
 ### Inbox Message Read All
 

From ad07d0a67398e4b6890249eef7bb8fc4b8c6680c Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 22:28:53 +0800
Subject: [PATCH 12/16] Fix docucheck warnings

---
 docs/Mobile-Token-API.md | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/docs/Mobile-Token-API.md b/docs/Mobile-Token-API.md
index 33c275b21..7935dff2d 100644
--- a/docs/Mobile-Token-API.md
+++ b/docs/Mobile-Token-API.md
@@ -192,6 +192,7 @@ Get the list with all operations that are pending confirmation.
   ]
 }
 ```
+<!-- end -->
 
 <!-- begin api POST /api/auth/token/app/operation/history -->
 ### Get History of Operations
@@ -296,6 +297,7 @@ Get the list of confirmed or rejected Mobile Token operations.
   ]
 }
 ```
+<!-- end -->
 
 <!-- begin api POST /api/auth/token/app/operation/authorize -->
 ### Confirm Operation
@@ -338,6 +340,7 @@ Confirms an operation with given ID and data. This endpoint requires a signature
   "status": "OK"
 }
 ```
+<!-- end -->
 
 <!-- begin api POST /api/auth/token/app/operation/cancel -->
 ### Reject Operation
@@ -492,6 +495,8 @@ Returned when PowerAuth authentication fails.
 }
 ```
 
+<!-- end -->
+
 <!-- begin api POST /api/push/device/register/token -->
 ### Register for Push Messages (Token)
 
@@ -663,6 +668,8 @@ Get count of unread messages in Inbox.
 }
 ```
 
+<!-- end -->
+
 <!-- begin api POST /api/inbox/message/list -->
 ### Inbox Message List
 
@@ -770,6 +777,8 @@ Get detail of a message in Inbox.
 }
 ```
 
+<!-- end -->
+
 <!-- begin api POST /api/inbox/message/read -->
 ### Inbox Message Read
 
@@ -811,6 +820,8 @@ Mark a message in inbox as read.
 }
 ```
 
+<!-- end -->
+
 <!-- begin api POST /api/inbox/message/read-all -->
 ### Inbox Message Read All
 
@@ -849,6 +860,3 @@ Mark all messages in inbox as read.
 ```
 
 <!-- end -->
-
-<!-- end -->
-

From 65f310d8cbb3b262a20c1bb3a82a1d23f45adf44 Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 22:34:44 +0800
Subject: [PATCH 13/16] Fix docucheck warnings

---
 docs/Configuration-Properties.md            | 7 ++++++-
 docs/onboarding/Configuration-Properties.md | 6 +++++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/docs/Configuration-Properties.md b/docs/Configuration-Properties.md
index bfb6bddb9..28e25bdcd 100644
--- a/docs/Configuration-Properties.md
+++ b/docs/Configuration-Properties.md
@@ -44,4 +44,9 @@ The Enrollment Server uses the following public configuration properties:
 | `powerauth.service.correlation-header.enabled` | `false` | Whether correlation header is enabled |
 | `powerauth.service.correlation-header.name` | `X-Correlation-ID` | Correlation header name |
 | `powerauth.service.correlation-header.value.validation-regexp` | `[a-zA-Z0-9\\-]{8,1024}` | Regular expression for correlation header value validation |
-| `logging.pattern.console` | [See application.properties](../enrollment-server/src/main/resources/application.properties#L82) | Logging pattern for console which includes the correlation header value |
+| `logging.pattern.console` | `_disabled_` | Logging pattern for console which includes the correlation header value |
+
+Sample setting of logging pattern:
+```properties
+logging.pattern.console=%clr(%d{${LOG_DATEFORMAT_PATTERN:yyyy-MM-dd HH:mm:ss.SSS}}){faint} %clr(${LOG_LEVEL_PATTERN:%5p}) [%X{X-Correlation-ID}] %clr(%5p) %clr(${PID: }){magenta} %clr(---){faint}%clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}
+```
diff --git a/docs/onboarding/Configuration-Properties.md b/docs/onboarding/Configuration-Properties.md
index 257af5287..43bb7b603 100644
--- a/docs/onboarding/Configuration-Properties.md
+++ b/docs/onboarding/Configuration-Properties.md
@@ -139,5 +139,9 @@ The Onboarding Server uses the following public configuration properties:
 | `powerauth.service.correlation-header.enabled` | `false` | Whether correlation header is enabled |
 | `powerauth.service.correlation-header.name` | `X-Correlation-ID` | Correlation header name |
 | `powerauth.service.correlation-header.value.validation-regexp` | `[a-zA-Z0-9\\-]{8,1024}` | Regular expression for correlation header value validation |
-| `logging.pattern.console` | [See application.properties](../../enrollment-server-onboarding/src/main/resources/application.properties#L172) | Logging pattern for console which includes the correlation header value |
+| `logging.pattern.console` | `_disabled_` | Logging pattern for console which includes the correlation header value |
 
+Sample setting of logging pattern:
+```properties
+logging.pattern.console=%clr(%d{${LOG_DATEFORMAT_PATTERN:yyyy-MM-dd HH:mm:ss.SSS}}){faint} %clr(${LOG_LEVEL_PATTERN:%5p}) [%X{X-Correlation-ID}] %clr(%5p) %clr(${PID: }){magenta} %clr(---){faint}%clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}
+```

From e43eeb11fd4fec27d6366915409bb75e7de00804 Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 22:47:26 +0800
Subject: [PATCH 14/16] Fix docucheck warnings

---
 docs/onboarding/Database-Structure.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/docs/onboarding/Database-Structure.md b/docs/onboarding/Database-Structure.md
index e9c6a7025..9ee022ed2 100644
--- a/docs/onboarding/Database-Structure.md
+++ b/docs/onboarding/Database-Structure.md
@@ -63,6 +63,8 @@ Stores onboarding processes created for tracking status of user onboarding.
 <!-- begin database table es_onboarding_otp -->
 ### Onboarding OTP Table
 
+#### Schema
+
 Stores onboarding OTP codes used during activation and user verification.
 
 | Name | Type | Info | Note |
@@ -86,6 +88,8 @@ Stores onboarding OTP codes used during activation and user verification.
 <!-- begin database table es_identity_verification -->
 ### Identity Verification Table
 
+#### Schema
+
 Stores information related to identity verification within an onboarding process.
 
 | Name | Type | Info | Note |
@@ -111,6 +115,8 @@ Stores information related to identity verification within an onboarding process
 <!-- begin database table es_document_verification -->
 ### Document Verification Table
 
+#### Schema
+
 Stores information related to document verification within an identity verification.
 
 | Name | Type | Info | Note |
@@ -145,6 +151,8 @@ Stores information related to document verification within an identity verificat
 <!-- begin database table es_document_data -->
 ### Document Data Table
 
+#### Schema
+
 Stores data for large documents (temporarily) during the identity verification.
 
 | Name | Type | Info | Note |
@@ -161,6 +169,8 @@ Stores data for large documents (temporarily) during the identity verification.
 <!-- begin database table es_document_result -->
 ### Document Result Table
 
+#### Schema
+
 Stores result of document verification.
 
 | Name | Type | Info | Note |

From 83d634d1e94efd58485511ad7de5280f110fd27e Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 22:48:49 +0800
Subject: [PATCH 15/16] Fix docucheck warnings

---
 docs/onboarding/Database-Structure.md | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/docs/onboarding/Database-Structure.md b/docs/onboarding/Database-Structure.md
index 9ee022ed2..70098372e 100644
--- a/docs/onboarding/Database-Structure.md
+++ b/docs/onboarding/Database-Structure.md
@@ -41,6 +41,8 @@ This chapter explains individual tables and their columns. The column types are
 
 Stores onboarding processes created for tracking status of user onboarding.
 
+#### Schema
+
 | Name | Type | Info | Note |
 |---|---|---|---|
 | `id` | `VARCHAR(36)` | `NOT NULL PRIMARY KEY` | Autogenerated record identifier (UUID). |
@@ -63,10 +65,10 @@ Stores onboarding processes created for tracking status of user onboarding.
 <!-- begin database table es_onboarding_otp -->
 ### Onboarding OTP Table
 
-#### Schema
-
 Stores onboarding OTP codes used during activation and user verification.
 
+#### Schema
+
 | Name | Type | Info | Note |
 |---|---|---|---|
 | `id` | `VARCHAR(36)` | `NOT NULL PRIMARY KEY` | Autogenerated record identifier (UUID). |
@@ -88,10 +90,10 @@ Stores onboarding OTP codes used during activation and user verification.
 <!-- begin database table es_identity_verification -->
 ### Identity Verification Table
 
-#### Schema
-
 Stores information related to identity verification within an onboarding process.
 
+#### Schema
+
 | Name | Type | Info | Note |
 |---|---|---|---|
 | `id` | `VARCHAR(36)` | `NOT NULL PRIMARY KEY` | Autogenerated record identifier (UUID). |
@@ -115,10 +117,10 @@ Stores information related to identity verification within an onboarding process
 <!-- begin database table es_document_verification -->
 ### Document Verification Table
 
-#### Schema
-
 Stores information related to document verification within an identity verification.
 
+#### Schema
+
 | Name | Type | Info | Note |
 |---|---|---|---|
 | `id` | `VARCHAR(36)` | `NOT NULL PRIMARY KEY` | Autogenerated record identifier (UUID). |
@@ -151,10 +153,10 @@ Stores information related to document verification within an identity verificat
 <!-- begin database table es_document_data -->
 ### Document Data Table
 
-#### Schema
-
 Stores data for large documents (temporarily) during the identity verification.
 
+#### Schema
+
 | Name | Type | Info | Note |
 |---|---|---|---|
 | `id` | `VARCHAR(36)` | `NOT NULL PRIMARY KEY` | Autogenerated record identifier (UUID). |
@@ -169,10 +171,10 @@ Stores data for large documents (temporarily) during the identity verification.
 <!-- begin database table es_document_result -->
 ### Document Result Table
 
-#### Schema
-
 Stores result of document verification.
 
+#### Schema
+
 | Name | Type | Info | Note |
 |---|---|---|---|
 | `id` | `BIGINT` | `NOT NULL PRIMARY KEY` | Autogenerated record identifier (Long). |

From 4b9493fc4f9679736d82fc73b5b801e48be591bc Mon Sep 17 00:00:00 2001
From: "roman.strobl@wultra.com" <roman.strobl@wultra.com>
Date: Mon, 13 Feb 2023 23:13:44 +0800
Subject: [PATCH 16/16] Add new offline flags

---
 docs/Offline-Signatures-QR-Code.md | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/docs/Offline-Signatures-QR-Code.md b/docs/Offline-Signatures-QR-Code.md
index deff55a47..94f448e6e 100644
--- a/docs/Offline-Signatures-QR-Code.md
+++ b/docs/Offline-Signatures-QR-Code.md
@@ -69,10 +69,13 @@ An exact details of the operation data structure can be found in the separate do
 
 | Flag | Meaning                      |
 |------|:-----------------------------|
-| `B`  | Operation can be signed with biometric factor |
+| `B`  | Operation can be signed with biometric factor     |
+| `X`  | The approval button will be flipped               |
+| `F`  | The fraud warning will be shown                   |
+| `C`  | Operation cannot be approved during a phone call  |
 
 Examples:
-- `B` - biometric 2FA is allowed
+- `BF` - biometric 2FA is allowed and fraud warning is shown
 - ` ` (empty string) - only knowledge factor is allowed for 2FA
 
 ## Signature