Update "How it works" section

src/components/Navigation.tsx

@@ -15,10 +15,10 @@ const SIGNATURES_CATEGORIES = ['Getting Started', 'GraphQL', 'Integrations', 'Gu
 
 const VERIFY_CATEGORIES = [
   'Getting Started',
+  'How it works',
   'eIDs',
   'Guides & Tools',
   'Integrations',
-  'How it works',
   'Reference',
 ];
 

src/pages/signatures/getting-started/register-application.mdx

@@ -8,7 +8,7 @@ subtitle: To interact with the Idura Signatures API, you must register a test ap
 
 ## Setting up a test application
 
-To start working with the Idura Signatures API and using the [GraphQL examples](/signatures/graphql/examples), you'll need to register a test application to obtain your client credentials (**Client ID** and **Client Secret**).
+To start working with the Idura Signatures API and using the [GraphQL examples](/signatures/graphql/examples), you'll need to register a test application to obtain your client credentials (**client ID** and **client secret**).
 
 To register a new Signatures application:
 

src/pages/signatures/graphql/examples.mdx

@@ -28,10 +28,10 @@ It is currently not possible to sign documents that have previously been signed,
 
 You can modify Idura Verify evidence provider settings to change the runtime behavior:
 
-- To change authentication methods displayed, add [`acrValues`](/verify/getting-started/oidc-intro#authorize-request-parameters).
+- To change authentication methods displayed, add [`acrValues`](/verify/reference/request-parameters/#acr_values).
 - To disable popups, set `"alwaysRedirect": true`.
-- To specify the user data you need, add the [OpenID Connect `scope`](/verify/getting-started/oidc-intro/#the-scope-parameter).
-- To add a message, use [`loginHint`](/verify/getting-started/oidc-intro/#the-loginhint-parameter).
+- To specify the user data you need, add [`scope`](/verify/reference/request-parameters/#scope).
+- To add a message, use [`loginHint`](/verify/reference/request-parameters/#login_hint).
 
 To experiment with different settings, see [Authorize URL builder](/verify/guides/authorize-url-builder/).
 

src/pages/verify/e-ids/finnish-trust-network.mdx

@@ -50,22 +50,22 @@ Please refer to the [Private Key JWT authentication guide](/verify/guides/privat
 ### Authentication request signing
 
 Your application must sign [authorization requests](/verify/reference/glossary/#authorization-request-authorize-url) to Idura and send them as JWT-secured Authorization Requests(JARs).
-A JWT-secured Authorization Request is a method where the [request parameters](/verify/getting-started/oidc-intro/#authorize-request-parameters) are encapsulated in a [JSON Web Token (JWT)](/verify/reference/glossary/#json-web-token-jwt) signed by your application’s private key and included in the authorization request via the `request` parameter.
+A JWT-secured Authorization Request is a method where the [request parameters](/verify/reference/request-parameters) are encapsulated in a [JSON Web Token (JWT)](/verify/reference/glossary/#json-web-token-jwt) signed by your application’s private key and included in the authorization request via the `request` parameter.
 
 Authentication request signing enhances security by guaranteeing that the request originated from your application and has not been tampered with. To understand the benefits in more detail, see: <a href="https://www.idura.eu/blog/signed-authorization-requests" target="_blank">Why Signed Authorization Requests Elevate Your Security</a>.
 
 #### Creating a signed authorization request
 
-To create a signed authorization request, you first create a JWT where the payload contains your [request parameters](/verify/getting-started/oidc-intro/#authorize-request-parameters), plus appropriate `issuer` and `audience`.
+To create a signed authorization request, you first create a JWT where the payload contains your request parameters, plus appropriate `issuer` and `audience`.
 The JWT is then signed using your application's private signing key and added to the authorization request via the `request` parameter. The private signing key used for [private key JWT client authentication](/verify/e-ids/finnish-trust-network/#private-key-jwt-client-authentication) can be used to sign authorization requests.
 
-Your signed authorization request will look something like this:
+If your [Idura domain](/verify/how-it-works/core-concepts/#domains) is `acme-corp.idura.broker`, your signed authorization request will look something like this:
 
 `https://acme-corp.idura.broker/oauth2/authorize?client_id=your_client_id&request=eyJhbGciOiJNilhcmxzZXYifQ.eyJpc3MiOiJ5b3VyX2Nsa9pZCI...`
 
 where the only two parameters directly included in the URL are:
 
-- `client_id`: contains the Client ID of your Idura application
+- `client_id`: contains the client ID of your Idura application
 - `request`: contains Request Object (the JWT whose claims hold the JSON-encoded authorization request parameters)
 
 The code sample below demonstrates creating a Request Object JWT, then building authorize URL in a Node.js/Express application.

src/pages/verify/e-ids/norwegian-bankid.mdx

@@ -270,13 +270,7 @@ _The [BankID OIDC Biometrics](#bankid-biometrics-assurance-level) option is **al
 
 ### Ordering the client credentials
 
-To order production credentials please send a request to
-
-<p style={{ textIndent: '50px' }}>
-  <a href="mailto:orders@idura.eu?subject=NO BankID for ...">orders@idura.eu</a>
-</p>
-
-with answers to these questions:
+To order production credentials please send a request to <a href="mailto:orders@idura.eu?subject=NO BankID for ...">orders@idura.eu</a> with answers to these questions:
 
 1. A short description of what your application does and why it needs BankID.
 2. Your company: _Name, organisation number, and address_.

src/pages/verify/e-ids/swedish-bankid.mdx

@@ -77,7 +77,10 @@ _Note_ that, as is also described on the website, using test BankID users does r
 
 ## BankID Phone Authentication
 
-<a href="https://www.bankid.com/en/foretag/telephone-identification" target="_blank">BankID in telephone calls</a> facilitates user authentication during a phone call.
+<a href="https://www.bankid.com/en/foretag/telephone-identification" target="_blank">
+  BankID in telephone calls
+</a>
+facilitates user authentication during a phone call.
 
 For details and integration instructions, please refer to [Caller Authentication with CIBA](/verify/guides/caller-authentication).
 
@@ -91,7 +94,7 @@ For instance you could render the QR flow in your own website, or trigger app2ap
 
 ### The underlying Headless flow
 
-Idura Verify facilitates Swedish BankID headless authentication via the [Headless flow](/verify/getting-started/oidc-intro/#authenticate-headless).
+Idura Verify facilitates Swedish BankID headless authentication via the [Headless flow](/verify/reference/authorization-flows/headless).
 
 ### Implementing BankID Headless Authentication
 

src/pages/verify/getting-started/dashboard-setup.mdx

@@ -14,7 +14,7 @@ This takes about two minutes and will give you the client credentials required t
 A [tenant](/verify/how-it-works/core-concepts/#tenants) represents your organization's isolated environment at Idura.
 
 1. [Sign up for a free test account](https://dashboard.idura.app/signup) to access the Idura Dashboard.
-2. You will be prompted to create your first tenant.
+2. You will be prompted to create your first tenant. _You can change the tenant name at any time after creation in the Dashboard **Settings**._
 
 <Highlight>
   **Risk-free testing**: Your free account includes a sandbox environment with unlimited test
@@ -58,9 +58,9 @@ import GenerateClientSecretSnippet from '../../../snippets/generate-client-secre
 
 <Highlight icon="circle-info">
   **Client secrets are for [server-side
-  applications](/verify/reference/glossary/#confidential-client) only.** If you are building a
-  Single Page Application or a native mobile app, you cannot securely store a secret. Use
-  **[PKCE](/verify/how-it-works/oidc-intro/#authenticate-with-pkce)** instead.
+  applications](/verify/reference/glossary/#confidential-clients) only.** If you are building a
+  Single-page application or a native mobile app, you cannot securely store a secret. Use
+  **[PKCE](/verify/reference/authorization-flows/pkce)** instead.
 </Highlight>
 
 If you lost your client secret or need to generate one, you can do so from your Application settings.

src/pages/verify/getting-started/production.mdx

@@ -48,7 +48,7 @@ issuance can take several business days depending on the eID provider.**
    - Go to the **Domains** tab and create a production domain.
      _Note that if you choose a domain that ends with something other than `idura.broker`, we recommend going with the Idura-managed option (**Managed SSL certificate**) for SSL certificate._
    - Go to the **Applications** tab and register your production application.
-     _The **Client ID** of your production application must be unique._
+     _The **client ID** of your production application must be unique._
 
 4. **Update your codebase.**
    Configure your website or application with the new production domain and API credentials.

src/pages/verify/guides/appswitch.mdx

@@ -24,7 +24,7 @@ You must augment the authorize request you send to Idura Verify so it contains o
 - `login_hint=appswitch:ios`
 - `login_hint=appswitch:android`
 
-The value must be sent in the `login_hint` query parameter. Further details on this (and other) parameters in an authorize request can be found [here](/verify/getting-started/oidc-intro#authorize-request-parameters).
+The value must be sent in the `login_hint` query parameter. For further details on this (and other) parameters in an authorize request, see [authorize request parameters](/verify/reference/authorize-request-parameters).
 
 Your app is responsible for sending the appropriate value for the platform it is deployed on.
 

src/pages/verify/guides/authorize-url-builder.mdx

@@ -2,8 +2,8 @@
 product: verify
 category: Guides & Tools
 sort: 0
-title: Authorize URL builder
-subtitle: Use our URL builder to explore the various features offers by Idura Verify and how to use them.
+title: Authorize URL Builder
+subtitle: Build authorization URLs with various parameters to explore the features offered by Idura Verify.
 ---
 
 import AuthorizeURLBuilder from '../../../components/AuthorizeURLBuilder';

src/pages/verify/guides/caller-authentication.mdx

@@ -15,7 +15,7 @@ This creates a secure, phishing-resistant way to confirm who you are talking to
 
 ## The CIBA flow
 
-Caller Authentication is built on the [**Client-Initiated Backchannel Authentication (CIBA) flow**](/verify/how-it-works/oidc-intro/#authenticate-with-ciba).
+Caller Authentication is built on the [**Client-Initiated Backchannel Authentication (CIBA) flow**](/verify/reference/authorization-flows/ciba).
 
 With CIBA, the client application provides a hint (e.g. the user's SSN) that triggers an authentication request to the user's device.
 The user can then approve the request and complete the authentication process on their device.
@@ -45,7 +45,7 @@ where the end-user doesn’t operate the client application—such as a call cen
 
 ### Implementing Caller Authentication with CIBA
 
-The CIBA flow is only available to traditional server-based web applications ([confidential clients](/verify/reference/glossary/#confidential-client)) and requires client validation for authentication requests.
+The CIBA flow is only available to traditional server-based web applications ([confidential clients](/verify/reference/glossary/#confidential-clients)) and requires client validation for authentication requests.
 We'll use [private key JWTs](/verify/guides/privatekey-jwt/) for authentication in the example below. An alternative (_less secure_) approach is to use `client_secret` for authentication.
 
 #### 1. Start the authentication request

src/pages/verify/guides/oidc-visualizer.mdx

@@ -3,7 +3,7 @@ product: verify
 category: Guides & Tools
 sort: 0
 title: OpenID Connect Visualizer
-subtitle: An interactive demo lets you run an OpenID Connect Authorization Code Flow and observe the entire process from sending an authentication request to obtaining and validating an ID token.
+subtitle: An interactive demo lets you run an OpenID Connect Authorization Code flow and observe the entire process from sending an authentication request to obtaining and validating an ID token.
 ---
 
 import OidcVisualizer from '../../../components/OidcVisualizer/OidcVisualizer';
@@ -20,12 +20,12 @@ If the authentication flow completes successfully, the client application receiv
 This visualizer lets you run the flow step by step and observe requests and responses exchanged between the **Client application**
 and **Idura Verify acting as the Authorization Server**, so you can understand what happens at every step.
 
-## Authorization Code Flow
+## Authorization Code flow
 
-[Authorization Code Flow](/verify/how-it-works/oidc-intro/#authenticate-with-back-channel-authorization-code-flow) is the most common OIDC flow for web applications.
+[Authorization Code flow](/verify/how-it-works/oidc-intro/#authorization-code-flow) is the most common OIDC flow for web applications.
 The diagram below shows how the Client Application and Authorization Server interact to complete this flow.
 
-![Authorization Code Flow ](./images/authorization_code_flow_diagram.png)
+![Authorization Code flow ](./images/authorization_code_flow_diagram.png)
 
 ## Try the Interactive Demo
 

src/pages/verify/guides/privatekey-jwt.mdx

@@ -79,9 +79,9 @@ The client assertion is a JWT signed by the private key of the [RSA key pair](/v
 
 `alg`: The algorithm used to sign the JWT. Should be set to `RS256`.
 
-`iss`: The Client ID of your Idura Verify application. You can find it in the General tab of your Application settings under `Client ID/Realm`.
+`iss`: The client ID of your Idura Verify application. You can find it in the General tab of your Application settings under `Client ID/Realm`.
 
-`sub`: Your application's Client ID (the same as in the `iss` claim).
+`sub`: Your application's client ID (the same as in the `iss` claim).
 
 `aud`: Your Idura Verify domain that will receive the assertion, e.g. `https://{{YOUR_IDURA_DOMAIN}}.idura.broker`.
 

src/pages/verify/guides/pushed-authorization-requests.mdx

@@ -9,8 +9,8 @@ title: Pushed Authorization Requests (PAR)
   Pushed Authorization Requests (PAR)
 </a>
 is an OAuth 2.0 extension that allows sending [authorization request
-parameters](/verify/how-it-works/oidc-intro/#authorize-request-parameters) to the authorization
-server via a POST request, rather than in the browser's URL query string.
+parameters](verify/reference/request-parameters/#authorization-endpoint) to the authorization server
+via a `POST` request, rather than in the browser's URL query string.
 
 PAR enhances security by mitigating risks associated with exposing sensitive data in URLs.
 It also allows the authorization server to authenticate the client and validate the request early in the process (before any user interaction occurs),
@@ -20,15 +20,15 @@ Using PAR improves [Telemetry & Observability](/verify/guides/telemetry/#par) fo
 it helps you trace authorization requests by giving you a `Trace-Id` to follow immediately and directly to your backend.
 
 PAR can be used with any [OpenID Connect flow](/verify/how-it-works/oidc-intro/#supported-openid-connect-flows) that involves authorization requests sent via the browser,
-including the [Authorization Code Flow](/verify/how-it-works/oidc-intro/#authenticate-with-back-channel-authorization-code-flow) and the [Authorization Code Flow with PKCE](/verify/how-it-works/oidc-intro/#authenticate-with-pkce).
+including the [Authorization Code flow](/verify/how-it-works/oidc-intro/#authorization-code-flow) and the [Authorization Code flow with PKCE](/verify/how-it-works/oidc-intro/#pkce-flow).
 
 ## How PAR works
 
 [Regular authorization requests](/verify/reference/glossary/#authorization-request-authorize-url) are made by redirecting the user's browser to the OAuth2 authorization endpoint (`/oauth2/authorize`) with all parameters included in the URL.
 
 The process with PAR is slightly different:
 
-- Your backend makes a POST request containing request parameters (_those you would otherwise include in the URL query string_) to the PAR endpoint (`/oauth2/par`).
+- Your backend makes a `POST` request containing request parameters (_those you would otherwise include in the URL query string_) to the PAR endpoint (`/oauth2/par`).
 - The authorization server responds with a `request_uri`, a unique identifier for your request.
 - Your application redirects the user's browser to the authorization server's authorization endpoint, including the `request_uri` obtained from the PAR response and the application's `client_id`.
 - The authorization server retrieves the original request parameters using the `request_uri` and proceeds with the authentication flow.
@@ -39,24 +39,24 @@ You can start using PAR in place of standard authorization requests by following
 
 ### 1: Push the authorization request from your backend
 
-Send a POST request from your backend to the PAR endpoint. The PAR endpoint URL can be found in your
+Send a `POST` request from your backend to the PAR endpoint. The PAR endpoint URL can be found in your
 [OIDC Discovery Document](/verify/reference/glossary/#oidc-discovery-document-well-knownopenid-configuration) under `pushed_authorization_request_endpoint`.
 
-Your POST request should include:
+Your `POST` request should include:
 
 - The same parameters you would normally send in an authorization request (e.g. `response_type`, `scope`, `redirect_uri`, `state`).
-  For the complete list of authorization request parameters, see [Authorize Request Parameters](/verify/how-it-works/oidc-intro/#authorize-request-parameters).
-- Client authentication credentials (for [confidential clients](/verify/reference/glossary/#confidential-client)):
+  For the complete list of authorization request parameters, see [authorize request parameters](/verify/reference/request-parameters/#authorization-endpoint).
+- Client authentication credentials (for [confidential clients](/verify/reference/glossary/#confidential-clients)):
   - either `client_id` and `client_secret` (included in the Basic Authorization header) or
   - `client_assertion` and `client_assertion_type` (included in the request body), when using [Private Key JWT](/verify/guides/privatekey-jwt/).
-- `code_challenge` and `code_challenge_method` (for [public clients](/verify/reference/glossary/#public-clients) or clients implementing [Authorization Code Flow with PKCE](/verify/how-it-works/oidc-intro/#authenticate-with-pkce)).
+- `code_challenge` and `code_challenge_method` (for [public clients](/verify/reference/glossary/#public-clients) or clients implementing [Authorization Code flow with PKCE](/verify/how-it-works/oidc-intro/#pkce-flow)).
 
 <Highlight icon="info">
 
-The [PKCE](/verify/reference/glossary/#pkce-proof-key-for-code-exchange) extension to the Authorization Code Flow is required for public clients and recommended for confidential clients.
+The [PKCE](/verify/reference/glossary/#pkce-proof-key-for-code-exchange) extension to the Authorization Code flow is required for public clients and recommended for confidential clients.
 It offers stronger protection against the misuse or injection of authorization codes, making your implementation more secure.
 
-For more details, see [OpenID Connect best security practices](/verify/how-it-works/best-security-practices/#authorization-code-flow).
+For more details, see [OpenID Connect security best practices](/verify/how-it-works/best-security-practices/#authorization-code-flow).
 
 </Highlight>
 
@@ -81,7 +81,7 @@ state=abc456
 
 ```http
 # Replace `YOUR_DOMAIN.idura.broker` with your Idura domain
-# Replace $client_id with the Client ID of your Idura Application
+# Replace $client_id with the client ID of your Idura Application
 # Replace `$client_assertion` with your JWT assertion
 # Replace `$your_return_url` with the redirect URI registered in your Idura application
 
@@ -100,7 +100,7 @@ state=abc456
 
 ```http
 # Replace `YOUR_DOMAIN.idura.broker` with your Idura domain
-# Replace $client_id with the Client ID of your Idura Application
+# Replace $client_id with the client ID of your Idura Application
 # Replace `$your_return_url` with the redirect URI registered in your Idura application
 
 POST https://YOUR_DOMAIN.idura.broker/oauth2/par HTTP/1.1