chore: fix typos and run pretty

docs/developer/02. Identity/01. Identity Process/00. Wallet Process.md

@@ -1,11 +1,11 @@
 ## Self-Sovereign-Identity
 
-Inside the catena-x world, managing your identity and data securely and efficiently is one of the key targets. Considering this, we implemented the usage of *Digital Wallet* and *Credentials* on Company level.
+Inside the Catena-x world, managing your identity and data securely and efficiently is one of the key targets. Considering this, we implemented the usage of **Digital Wallet** and **Credentials** on Company level.
 
 ### What is a Digital Wallet?
 
-A **Digital Wallet** in the context of a dataspace is an identity wallet of an company (note: it can be many other things as well, but in the context of the CX iomplementation we are talking about company identities). In detail: it holds your credentials, identity information, and potentially other company data. It's like a virtual safe where your digital identity components are stored securely. Your digital wallet can authenticate you across various platforms and services within the dataspace without the need to repeatedly enter your personal information.
-In the concept of the digital wallet the concept of own and managed wallet.
+A **Digital Wallet** in the context of a dataspace is an identity wallet of an company (note: it can be many other things as well, but in the context of the CX implementation we are talking about company identities). In detail: it holds your credentials, identity information, and potentially other company data. It's like a virtual safe where your digital identity components are stored securely. Your digital wallet can authenticate you across various platforms and services within the dataspace without the need to repeatedly enter your personal information.
+Within the concept of the digital wallet are the concepts of own and managed wallets.
 
 In the current implementation state of the datapsace only one wallet is supported, but extending to multiple wallets (managed as well as own) is planned shortly.
 
@@ -16,17 +16,16 @@ In the current implementation state of the datapsace only one wallet is supporte
 ### Which roles play a game in the wallet/credential management?
 
 1. **Issuer**: Trusted entities in the dataspace issue digital credentials after verifying your identity or certifications. These credentials are then securely stored in your digital wallet.
-Trusted issuer of the catena-x dataspace are certified and available via the 'SSI Authority & Schema Registry'.
-
-2. **Wallet provider**: Wallet service provider which offer managed wallets for dataspace participants. Status: Coming Soon
+   Trusted issuer of the Catena-x dataspace are certified and available via the 'SSI Authority & Schema Registry'.
 
+2. **Wallet provider**: Wallet service provider which offer managed wallets for dataspace participants. Status: Coming Soon.
 
 ### Important Links - Get to the implementation
 
 - Wallet Creation
-- Get a Credentila (UseCase)
+- Get a Credential (UseCase)
 - Get a Credential (CompanyRoles)
-- Issuer Component - *coming soon*
+- Issuer Component - **coming soon**
 
 <br>
 <br>

docs/developer/02. Identity/02. Wallet Creation/00. Wallet Creation.md

@@ -2,8 +2,8 @@
 
 ### Wallet Creation
 
-The wallet tenant per company is created as part of the dataspace registration.
-This includes a didWeb.
+As part of the dataspace registration a wallet tenant per company is created.
+This includes a DID Web.
 The managed identity wallet is created and new credentials are issued by th portal.
 A direct interface by the user is not provided.
 

docs/developer/02. Identity/03. Credential Management/01. Get UseCase Credential.md

@@ -26,7 +26,7 @@ Functional Description: [here](/docs/user/06.%20Certificates/01.%20UseCase%20Par
 <br>
 
 The available credential types are fetched from the portal db company_ssi_details and verified_credential_external_type_use_case_detail_versions.
-The api response (see below) automatically includes the "ssiDetailData" which include the actual acting user company credential status. (e.g. if the company has one or several credentials of the use case framework requested or active already, it will be shown/displayed in the "ssiDetailData" section)
+The api response (see below) automatically includes the "ssiDetailData" which includes the actual acting user company credential status. (e.g. if the company has one or several credentials of the use case framework requested or already active, it will be shown/displayed in the "ssiDetailData" section).
 
 ```diff
 ! GET /api/administration/companydata/useCaseParticipation
@@ -70,7 +70,7 @@ Request Body
 
 ### Submit Credential request
 
-As part of the credential request submission (which is only possible if there is no PENDING request for the credential and version existing yet) the signed framework agreement need to get submitted.
+As part of the credential request submission (which is only possible if there is no PENDING request for the credential and version existing yet) the signed framework agreement needs to get submitted.
 
 ```diff
 ! POST /api/administration/companydata/useCaseParticipation

docs/developer/02. Identity/03. Credential Management/02. Other Certificates.md

@@ -1,6 +1,6 @@
 ## Company Certificates
 
-Beside the Use Case Frameworks, companies can apply/request for other kind of company certificates as well.
+Beside the Use Case Frameworks, companies can apply/request for other kinds of company certificates as well.
 
 Currently Supported:
 
@@ -62,8 +62,8 @@ Response Body
 
 ### Available Certificate Document Requests
 
-With the page load, the GET /certificateTypes endpoint is triggered which gets used to manage the "Upload Certificate" Button as well as the overlay content.
-The endpoint only response with those certificate types which the user company can actually request.
+With the page load, the GET /certificateTypes endpoint is triggered which gets used to manage the "Upload Certificate" button as well as the overlay content.
+The endpoint responds only with those certificate types which the user company can actually request.
 
 Backend Logic:
 
@@ -92,7 +92,7 @@ Backend Logic:
 
 ### Submit Certificate request
 
-As part of the credential request submission (which is only possible if there is no PENDING request for the credential and version existing yet) the signed framework agreement need to get submitted.
+As part of the credential request submission (which is only possible if there is no PENDING request for the credential and version yet existing) the signed framework agreement needs to get submitted.
 
 ```diff
 ! POST /api/administration/companydata/certificates

docs/developer/02. Identity/03. Credential Management/03. Credential Admin Board.md

@@ -166,7 +166,7 @@ Request Body
 
 #### Reject Credential Request
 
-With the credential reject button, the credential request decline endpoint is triggered (see details below) additionally, following task will get executed
+With the credential reject button, the credential request decline endpoint is triggered (see details below) additionally, following task will get executed:
 
 - credential request is getting set to "Inactive" (table: company_ssi_details)
 - the requester company is getting informed about the rejection/decline of the credential and is allowed to start a new request (via email)

docs/developer/02. Identity/04. Wallet UI/01. Wallet UI.md

@@ -31,10 +31,9 @@ With the implementation of 24.05. a change is planned.
 
 <br>
 
-
 #### API Connection
 
-Calling the configured wallet solution (as per the env. file config) endpoint 
+Calling the configured wallet solution (as per the env. file config) endpoint
 
 ```
 GET /api/credentials