docs: finalize release-readiness cleanup and consistency fixes

Apply low-risk documentation polish for production readiness by fixing legacy references, certificate guidance links, homepage messaging, and sidebar consistency while removing orphaned pages.

Author: phaupt

docs/.vitepress/config.mts

@@ -95,7 +95,7 @@ export default withMermaid(defineConfig({
         },
         {
           text: '',
-          items: [{ text: 'Imprint', link: '/rest-api-guide/imprint.md' }]
+          items: [{ text: 'Imprint', link: '/rest-api-guide/imprint' }]
         }
 
       ],
@@ -108,13 +108,13 @@ export default withMermaid(defineConfig({
             { text: 'Best Practices', link: '/oidc-integration-guide/best-practices' },
             { text: 'Passkey Authentication', link: '/oidc-integration-guide/passkey-authentication' },
             { text: 'Public Cloud Integration', link: '/oidc-integration-guide/cloud-integration-guide' },
-            { text: 'MobileID OIDC - Use Cases', link: '/oidc-integration-guide/oidc-use-cases' },
+            { text: 'Use Cases', link: '/oidc-integration-guide/oidc-use-cases' },
             { text: 'App Message Formats', link: '/oidc-integration-guide/message-formats' }
           ]
         },
         {
           text: '',
-          items: [{ text: 'Imprint', link: '/oidc-integration-guide/imprint.md' }]
+          items: [{ text: 'Imprint', link: '/oidc-integration-guide/imprint' }]
         }
       ],
 
@@ -131,7 +131,7 @@ export default withMermaid(defineConfig({
         },
         {
           text: '',
-          items: [{ text: 'Imprint', link: '/radius-interface-gateway-guide/imprint.md' }]
+          items: [{ text: 'Imprint', link: '/radius-interface-gateway-guide/imprint' }]
         }
       ]
 

docs/index.md

@@ -33,7 +33,7 @@ features:
 <div class="vp-doc">
 
 <div class="wip-banner">
-  <strong>🚧 Work in Progress: We're actively building this documentation. Check back regularly for the latest updates.</strong> 
+  This documentation is actively maintained and updated as Mobile ID evolves. Use <em>"Give feedback on this page"</em> to suggest improvements.
 </div>
 
 </div>

docs/oidc-integration-guide/introduction.md

@@ -46,7 +46,7 @@ Mobile ID utilizes the **Authorization Code Grant Type** to obtain an access tok
 
 ## Refresh Token
 
-Because Access Tokens are always short-lived (see [Section Tokens](/oidc-integration-guide/getting-started#tokens)), a Relying Party may want to refresh the Access Token using their long-lived Refresh Token. To refresh an Access Token, the Client must always authenticate at the Token Endpoint. The Relying Party should always validate the Refresh Response.
+Because Access Tokens are always short-lived (see [Tokens](/oidc-integration-guide/getting-started#tokens)), a Relying Party may want to refresh the Access Token using their long-lived Refresh Token. To refresh an Access Token, the Client must always authenticate at the Token Endpoint. The Relying Party should always validate the Refresh Response.
 
 ![refresh-token](/img/refresh-token.png)
 

docs/radius-interface-gateway-guide/rig-deployment.md

@@ -34,7 +34,7 @@ When constructing an MSS Signature request, the following best-practice guidelin
 
 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).
+   - Encoded in UTF-8.
    - 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 03.38](https://en.wikipedia.org/wiki/GSM_03.38) character set.
@@ -44,12 +44,6 @@ When constructing an MSS Signature request, the following best-practice guidelin
    **Example DTBD:**
    > `Bank ACME: Proceed with the login? (TXN-3D5K)`
 
-::: details Footnotes
-17. <span id="17"></span> Type of the AP_TransID is xsd:NCName, refer to http://www.datypic.com/sc/xsd/t-xsd_NCName.html [↩](#a17)
-18. <span id="17"></span> http://www.w3.org/TR/xmlschema-2/#dateTime [↩](#a17)
-19. <span id="17"></span> http://en.wikipedia.org/wiki/UTF-8 [↩](#a17)
-20. <span id="17"></span> In mobile telephony GSM 03.38 is the standard character set used in short message service. [↩](#a17)
-:::
 
 ### Signature Response
 
@@ -72,7 +66,7 @@ The key validation aspects are as follows:
    - 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**.
+   - For the highest level of assurance and a fully strong two-factor authentication process, validate the Mobile ID serial number as described in **[Serial Number Validation](/rest-api-guide/best-practices#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.
@@ -94,7 +88,7 @@ If both signature requests target the SIM-based authentication method, and the f
 
 - **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 **[Status and Fault Codes](/rest-api-guide/status-fault-codes)** for detailed fault code definitions.
 
 ##### App Method Concurrency
 If both requests target the Mobile ID App-based authentication method, the behavior is different:
@@ -103,7 +97,7 @@ If both requests target the Mobile ID App-based authentication method, the behav
 - 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 **[Status and Fault Codes](/rest-api-guide/status-fault-codes)** for further information.
 
 ## Serial Number Validation
 

docs/rest-api-guide/best-practices.md

@@ -26,17 +26,17 @@ $ openssl req -new -newkey rsa:4096 -nodes -rand /dev/urandom \
 
 ### Self-Sign Certificate
 
-```bash
-
-$ openssl x509 -req -days 1825 -sha256 -in mycert.csr -signkey mycert.key -out my-cert.crt
+Create a small extension file `ext.cnf` that adds the required Client Authentication Extended Key Usage:
 
+```ini
+[v3_req]
+extendedKeyUsage = clientAuth
 ```
 
-and run:
+Then self-sign the certificate:
 
 ```bash
-
-$ openssl x509 -req -days 1825 -sha256 -extfile ext.cnf \
+$ openssl x509 -req -days 1825 -sha256 -extfile ext.cnf -extensions v3_req \
   -in mycert.csr -signkey mycert.key -out mycert.crt
 ```
 

docs/rest-api-guide/create-client-certs.md

@@ -28,14 +28,14 @@ Usually, a client's TrustStore contains the Root Certificate only, the so-called
 The Mobile ID End Entity Certificate is either based on the Root Certificate `Swisscom Root CA 4` or on the older Root Certificate `Swisscom Root CA 2`.
 
 You can download the "Swisscom Root CA 4" certificate from the Swisscom Digital Certificate Service site:
-[http://aia.swissdigicert.ch/sdcs-root4.crt](http://aia.swissdigicert.ch/sdcs-root4.crt)
+[https://aia.swissdigicert.ch/sdcs-root4.crt](https://aia.swissdigicert.ch/sdcs-root4.crt)
 
 | SHA-1 Fingerprint |
 |-------------------|
 | B9 82 1B 0C 87 7D 30 24 DD 6A 8F 6E 44 3E F5 38 8E 53 16 1B |
 
 You can download the "Swisscom Root CA 2" certificate from the Swisscom Digital Certificate Service site:
-[http://aia.swissdigicert.ch/sdcs-root2.crt](http://aia.swissdigicert.ch/sdcs-root2.crt)
+[https://aia.swissdigicert.ch/sdcs-root2.crt](https://aia.swissdigicert.ch/sdcs-root2.crt)
 
 | SHA-1 Fingerprint |
 |-------------------|

docs/rest-api-guide/root-ca-certs.md

@@ -10,7 +10,7 @@
 | 501 | REVOKED_CERTIFICATE | The Mobile ID user's x509 certificate has been revoked. The user must re-activate the account on the Mobile ID self-care portal. | Signature, Status Query |
 | 502 | VALID_SIGNATURE | The MSS Signature transaction was successful. | Signature, Status Query |
 | 503 | INVALID_SIGNATURE | The MSS Signature transaction failed due to invalid signature data. The user may try to re-activate the account on the Mobile ID self-care portal. It may be required to replace the SIM card. | Signature, Status Query |
-| 504 | OUSTANDING_TRANSACTION | The MSS Signature transaction is outstanding. The AP must try again later. | Status Query |
+| 504 | OUTSTANDING_TRANSACTION | The MSS Signature transaction is outstanding. The AP must try again later. | Status Query |
 
 ### Fault Codes (Error)
 
@@ -39,7 +39,7 @@
 
 Specific MSISDNs are available to test different type of response status and fault codes. By placing a request to one of this number the related status or fault code will be raised. The following MSISDN structure is used for testing fault codes, which might help a developer to test the error handling of their Mobile ID client.
 
-- `+41000092<faultcode>` - Use one of the 3-digit fault sub-code values listed in section 6.1.
+- `+41000092<faultcode>` - Use one of the 3-digit fault sub-code values listed in the [Fault Codes](#fault-codes-error) table above.
 
 On the other hand, a successful Mobile ID signature response can be tested by using one of the two MSISDNs listed below, which might help with CI/CD pipelines that include automated regression testing with Mobile ID authentications. However, your account will require specific permissions to be able to use the test-MSISDNs for successful Mobile ID responses. Please ask your Swisscom contact if you need this permission.