docs: shorten navigation titles to max 30 characters

Truncate sidebar and "On this page" headings that exceeded 30 chars
for better readability in the navigation bars.

Author: phaupt

docs/.vitepress/config.mts

@@ -78,7 +78,7 @@ export default defineConfig({
             { text: 'Best Practices', link: '/oidc-integration-guide/best-practices' },
             { text: 'Public Cloud Integration Guide', link: '/oidc-integration-guide/cloud-integration-guide' },
             { text: 'MobileID OIDC - Use Cases', link: '/oidc-integration-guide/oidc-use-cases' },
-            { text: 'Message Formats on the Mobile ID App', link: '/oidc-integration-guide/message-formats' }
+            { text: 'App Message Formats', link: '/oidc-integration-guide/message-formats' }
           ]
         },
         {

docs/oidc-integration-guide/best-practices.md

@@ -1,8 +1,8 @@
 # Best Practices
 
-## Pushed Authorization Request (PAR)
+## Pushed Auth Request (PAR)
 
-### Back-channel submission of authorisation parameters
+### Back-channel PAR Submission
 
 The Pushed Authorisation Request (PAR) endpoint gives OAuth 2.0 clients a back-channel to post the parameters of an authorisation request to the Mobile ID server, to obtain an opaque URI handle for them, and then continue with the frontend redirection to the authorisation endpoint as usual.
 
@@ -105,13 +105,13 @@ Provide state and nonce values with sufficient entropy.
 - [OIDC Core — AuthRequest](http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest)
 - [OIDC Core — NonceNotes](http://openid.net/specs/openid-connect-core-1_0.html#NonceNotes)
 
-### Validate authentication responses
+### Validate Auth Responses
 
 Handle the state parameter correctly.
 
 - [OIDC Core — AuthResponseValidation](http://openid.net/specs/openid-connect-core-1_0.html#AuthResponseValidation)
 
-### Validate token endpoint responses
+### Validate Token Responses
 
 Validate the ID Token and verify scopes.
 

docs/oidc-integration-guide/introduction.md

@@ -15,7 +15,7 @@ See [OpenID Connect FAQ](https://openid.net/connect/faq/) for a set of answers t
 The Mobile ID solution protects access to your company data and applications with a comprehensive end-to-end solution for a strong multi-factor authentication (MFA). Please visit [mobileid.ch](https://mobileid.ch) for further information. Do not hesitate to contact us in case of any questions.
 
 
-## Basic Key Concepts – Terminology
+## Key Concepts & Terminology
 
 The most basic key concepts are as follows.
 

docs/oidc-integration-guide/message-formats.md

@@ -129,7 +129,7 @@ GET /oidc/authorize?
 Request an App ACR (e.g., `mid_al3_mobileapp`) if you want to ensure the App method is selected.
 :::
 
-## What exactly is signed (classic vs. Transaction Approval)
+## Signed Data Comparison
 
 **Classic DTBD:** the service signs the visible text string.
 

docs/oidc-integration-guide/oidc-use-cases.md

@@ -19,7 +19,7 @@ If the request contains a `login_hint` parameter with the user's phone number, t
 ![use-case-msisdn-rp-knows](/img/use-case-msisdn-rp-knows.png)
 
 
-## Prompt user for user credentials
+## Prompt for User Credentials
 
 If the request contains a `login_hint` parameter set to `useLDAP:true` and a `prompt` parameter set to `login`, the result will be that the user must enter the user credentials on the MobileID side, as shown in the figure below. This is a typical **B2B** scenario, for example the MobileID login to a company service.
 

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

@@ -110,7 +110,7 @@ If both requests target the Mobile ID App-based authentication method, the behav
 - **Fault Code (cancellation of first transaction):** `401 / USER_CANCEL`
 - See **Section 6** for further information.
 
-## Mobile ID Serial Number Validation
+## Serial Number Validation
 
 With an MSS Signature response, you will get signature data and the mobile user's X.509 certificate, which contains the public key required to validate the signature data.
 

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

@@ -3,7 +3,7 @@
 There are two different scenarios (described in the two chapters below) to consider, where x.509 certificates are involved. Since they do not have the same root CA, you must ensure that your client's TrustStore contains all involved "Root CA" certificates.
 
 
-## Mobile ID X509 Server Certificate
+## X509 Server Certificate
 
 As described in [Section Mutual Authentication](/rest-api-guide/app-provider-client-integration.html#mutual-authentication), the Mobile ID server's x.509 certificate that is used in the mutual SSL/TLS authentication process is a SwissSign certificate.
 
@@ -15,7 +15,7 @@ You can download the "SwissSign Gold CA - G2" certificate from the SwissSign sit
 | D8 C5 38 8A B7 30 1B 1B 6E D4 7A E6 45 25 3A 6F 9F 1A 27 61 |
 
 
-## Mobile ID User X509 Certificate
+## User X509 Certificate
 
 As described in [Section MSS Signature](/rest-api-guide/mobile-id-api.html#mss-signature), the main scenario is a strong authentication, where the AP receives a signature response, which includes the signature object and the mobile user's x.509 certificate (public key). The AP should validate the signature as well as the x.509 certificate's trust chain.