Merge pull request #3 from MobileID-Strong-Authentication/docs/fix-reference-guide-typos

replace wrong whitespace char

Author: phaupt

docs/index.md

@@ -25,7 +25,7 @@ features:
     icon:
       src: /img/icon-security.svg
       class: feature-icon-security
-    details: Follow this guide to integrate Mobile ID into your application through the OpenID Connect (OIDC) standard.
+    details: Follow this guide to integrate Mobile ID into your application through the OpenID Connect (OIDC) standard.
     link: /oidc/introduction
   - title: Release Notes
     icon:

docs/reference-guide/app-provider-client-integration.md

@@ -1,6 +1,6 @@
-# Application Provider Client Integration
+# Application Provider Client Integration
 
-This chapter describes how an **Application Provider (AP)** integrates its backend with the **Swisscom Mobile ID signature service**. It covers the necessary preconditions, endpoint configuration, and use of **mutual TLS authentication**.
+This chapter describes how an **Application Provider (AP)** integrates its backend with the **Swisscom Mobile ID signature service**. It covers the necessary preconditions, endpoint configuration, and use of **mutual TLS authentication**.
 
 ## Preconditions
 
@@ -14,10 +14,10 @@ Before using the **Swisscom Mobile ID** web service, some initial provisioning s
 2. **The Mobile ID customer receives from Swisscom:**
    - An **AP_ID** (Application Provider Identifier) value.
    - A **DataToBeDisplayed (DTBD) Prefix** value:
-     - The DTBD Prefix is an AP‑specific keyword that must be included as a prefix in every Mobile ID request text message sent to a Mobile ID user (the message displayed on the user’s mobile phone).
+     - The DTBD Prefix is an AP‑specific keyword that must be included as a prefix in every Mobile ID request text message sent to a Mobile ID user (the message displayed on the user’s mobile phone).
      - **Example:** `"Bank ACME: "`
 
-## Endpoint Address
+## Endpoint Address
 
 The Swisscom Mobile ID web service is accessible through LAN-I  or Internet. If not otherwise specified use the following default access details.
 
@@ -85,11 +85,11 @@ A certificate-based mutual authentication when accessing the Mobile ID web servi
 - The **Enhanced Key Usage** value of client certificates must include **Client Authentication** (`1.3.6.1.5.5.7.3.2`).
   - See **[Create X509 Client Certificates](/reference-guide/create-client-certs.md)** for examples of creating self‑signed certificates.
 
-- All requests to the **Mobile ID service** must originate **only** from servers that you control.
+- All requests to the **Mobile ID service** must originate **only** from servers that you control.
   - Never send requests directly from client‑side code such as **mobile apps** or **JavaScript**, as this may compromise your credentials.
 
-- To validate the **chain of trust** for the Mobile ID server certificate:
-  - Add the **SwissSign Gold CA – G2** root certificate to your client **TrustStore**.
+- To validate the **chain of trust** for the Mobile ID server certificate:
+  - Add the **SwissSign Gold CA – G2** root certificate to your client **TrustStore**.
   - The intermediate CAs are returned dynamically by the MID server and may change.
 
 ::: info

docs/reference-guide/best-practices.md

@@ -1,10 +1,10 @@
 # Best Practices
 
-The **Swisscom Mobile ID Strong Authentication** GitHub repository provides various examples of Mobile ID client implementations.
+The **Swisscom Mobile ID Strong Authentication** GitHub repository provides various examples of Mobile ID client implementations.
 
-The repository **[`mobileid-client-java`](https://github.com/SwisscomTrustServices/mobileid-client-java)** serves as the *main* Java‑based reference implementation for building **Mobile ID REST** and **SOAP** API clients.
+The repository **[`mobileid-client-java`](https://github.com/SwisscomTrustServices/mobileid-client-java)** serves as the *main* Java‑based reference implementation for building **Mobile ID REST** and **SOAP** API clients.
 
-This library is ideal for Java 8+ projects that require **secure authentication and authorization** using a mobile phone.
+This library is ideal for Java 8+ projects that require **secure authentication and authorization** using a mobile phone.
 It can be added as a dependency to your project and used in any scenario requiring access to the **Swisscom Mobile ID** service.
 
 ## MSS Signature
@@ -13,13 +13,13 @@ It can be added as a dependency to your project and used in any scenario requiri
 
 When constructing an **MSS Signature** request, the following best‑practice guidelines should be followed:
 
-1. **Define a unique `AP_TransID` (Transaction ID)**
+1. **Define a unique `AP_TransID` (Transaction ID)**
    Each signature request must have a unique transaction identifier.
 
 2. **Set the current time for `Instant` (with time zone)**
-   The `Instant` parameter must include time zone information and must not deviate excessively from the Mobile ID Service’s current time; otherwise, a fault response with sub‑code **101** will be returned.
+   The `Instant` parameter must include time zone information and must not deviate excessively from the Mobile ID Service’s current time; otherwise, a fault response with sub‑code **101** will be returned.
    - **Example:** `2020-01-01T12:00:00.000+01:00`
-   - Must conform to the [W3C `xs:dateTime`](https://www.w3.org/TR/xmlschema-2/#dateTime) format.
+   - Must conform to the [W3C `xs:dateTime`](https://www.w3.org/TR/xmlschema-2/#dateTime) format.
 
 3. **Ensure uniqueness across the triplet `(AP_ID, AP_TransID, Instant)`**
    The combination of these three fields must be unique for every transaction.
@@ -31,19 +31,19 @@ When constructing an **MSS Signature** request, the following best‑practice gu
    - **Example:** `+41791234567`
 
 5. **Set a valid `UserLang` value**
-   The value must be one of the supported languages — **EN**, **DE**, **FR**, or **IT** — and must match the language used in the **DataToBeDisplayed** (`DTBD`) message.
+   The value must be one of the supported languages — **EN**, **DE**, **FR**, or **IT** — and must match the language used in the **DataToBeDisplayed** (`DTBD`) message.
 
 6. **Define the `DataToBeDisplayed` (DTBD) message**
    The text shown on the user’s mobile device must comply with the following guidelines:
    - Encoded in **UTF‑8** [<sup id="a17">17</sup>](#17).
-   - Should include a **unique transaction reference** (e.g., timestamp, customer ID, contract ID).
+   - Should include a **unique transaction reference** (e.g., timestamp, customer ID, contract ID).
    - **Length limits:**
-     - Maximum **239 characters** if all characters are in the standard GSM DA character set.
-     - If any character falls outside this set (e.g., the lowercase cedilla “ç”), the maximum length reduces to **119 characters**.
+     - Maximum **239 characters** if all characters are in the standard GSM DA character set.
+     - If any character falls outside this set (e.g., the lowercase cedilla “ç”), the maximum length reduces to **119 characters**.
    - Keep the message as **short and user‑friendly** as possible.
 
    **Example DTBD:**
-   > `Bank ACME: Proceed with the login? (TXN‑3D5K)`
+   > `Bank ACME: Proceed with the login? (TXN‑3D5K)`
 
 ---
 
@@ -61,26 +61,26 @@ When constructing an **MSS Signature** request, the following best‑practice gu
 
 ### Signature Response
 
-After receiving the **MSS Signature Response**, the client (Application Provider – AP) must perform proper response validation to ensure authenticity, integrity, and consistency with the original request.
+After receiving the **MSS Signature Response**, the client (Application Provider – AP) must perform proper response validation to ensure authenticity, integrity, and consistency with the original request.
 
 The key validation aspects are as follows:
 
 1. **Match Request and Response Identifiers**
    - Verify that the **`AP_TransID`** and **`MSISDN`** values in the response are identical to those sent in the original request.
    - Any mismatch should be treated as an invalid response and rejected.
 
-2. **Validate the Mobile User’s X.509 Certificate**
+2. **Validate the Mobile User’s X.509 Certificate**
    - Ensure the user certificate chains up to a **trusted root CA** contained in your local **TrustStore**.
-   - The client should only trust certificates that link to a **trust anchor** matching the expected Swisscom Mobile ID CA.
-   - Your **TrustStore** should only contain the **relevant root CA certificate** (see **[Root CA Certificates](/reference-guide/root-ca-certs.md)**).
+   - The client should only trust certificates that link to a **trust anchor** matching the expected Swisscom Mobile ID CA.
+   - Your **TrustStore** should only contain the **relevant root CA certificate** (see **[Root CA Certificates](/reference-guide/root-ca-certs.md)**).
 
-3. **Verify the Digital Signature**
+3. **Verify the Digital Signature**
    - Confirm that the received digital signature is **cryptographically valid**.
    - The **signed content** must correspond exactly to the **`DataToBeDisplayed (DTBD)`** text from the earlier signature request.
    - The client must be capable of validating both **RSA** and **ECDSA** signatures.
 
-4. **(Optional) Validate the Mobile ID Serial Number**
-   - For the **highest level of assurance** and a fully **strong two‑factor authentication** process, validate the **Mobile ID serial number** as described in **Section Mobile ID Serial Number Validation**.
+4. **(Optional) Validate the Mobile ID Serial Number**
+   - For the **highest level of assurance** and a fully **strong two‑factor authentication** process, validate the **Mobile ID serial number** as described in **Section Mobile ID Serial Number Validation**.
 
 5. **Implement Proper Fault and Status Handling**
    - Handle all **status** and **fault codes** using structured exception handling logic to ensure stable, predictable behavior of the client application.
@@ -89,14 +89,14 @@ The key validation aspects are as follows:
 
 **Important Note:**
 Certificate revocation checks are **not recommended**.
-Mobile ID user certificates are **never revoked** individually — the **Mobile ID service backend** manages account validity and state directly.
+Mobile ID user certificates are **never revoked** individually — the **Mobile ID service backend** manages account validity and state directly.
 
 
 ### Signature Concurrency Control
 
-This section describes the behavior of the **Mobile ID Service** when an **Application Provider (AP)** submits a new **MSS Signature** request while another signature transaction is already in progress for the **same MSISDN** and the **same authentication method**.
+This section describes the behavior of the **Mobile ID Service** when an **Application Provider (AP)** submits a new **MSS Signature** request while another signature transaction is already in progress for the **same MSISDN** and the **same authentication method**.
 
-Concurrency handling depends on whether the request targets the **SIM** method or the **Mobile ID App** method.
+Concurrency handling depends on whether the request targets the **SIM** method or the **Mobile ID App** method.
 
 ---
 
@@ -105,18 +105,18 @@ If both signature requests target the **SIM‑based authentication method**, and
 
 - **Fault Code:** `406 / PB_SIGNATURE_PROCESS`
 - **Description:** The subscriber already has an active signature operation in process.
-- See **Section 6** for detailed fault code definitions.
+- See **Section 6** for detailed fault code definitions.
 
 ---
 
 ##### App Method Concurrency
-If both requests target the **Mobile ID App‑based authentication method**, the behavior is different:
+If both requests target the **Mobile ID App‑based authentication method**, the behavior is different:
 
 - The **existing first signature transaction** is **canceled** automatically by the backend.
-- The **second signature request** is then displayed on the mobile device via the Mobile ID App.
+- The **second signature request** is then displayed on the mobile device via the Mobile ID App.
 
 - **Fault Code (cancellation of first transaction):** `401 / USER_CANCEL`
-- See **Section 6** for further information.
+- See **Section 6** for further information.
 
 ## Mobile ID Serial Number Validation