diff --git a/docs/annexes/annex-09-design-guide-data-sharing-scenarios.md b/docs/annexes/annex-09-design-guide-data-sharing-scenarios.md
index 6a450d2..fd61650 100644
--- a/docs/annexes/annex-09-design-guide-data-sharing-scenarios.md
+++ b/docs/annexes/annex-09-design-guide-data-sharing-scenarios.md
@@ -32,7 +32,7 @@ In relation to the remote flows, it shall be noted that the data exchange occurs
 
 In contrast, in the 'remote cross-device' flow, the EUDI Wallet user
 consumes information from a Relying Party service on another device than
-the EUDI Wallet device, e.g. user visits the relying party's service on
+the EUDI Wallet device, e.g. user visits the Relying Party's service on
 their web browser on a PC and uses the EUDI Wallet app to scan a QR Code
 on a login page in order to get access to a service provided by the
 Relying Party.
@@ -181,7 +181,7 @@ consent.
 -   **Transparency and Clarity**: Transparency is key in ensuring that
     users are always aware of what information is being presented. The
     EUDI Wallet should include clear and concise explanations about the
-    purpose of each data request, the relying party\'s identity, and how
+    purpose of each data request, the Relying Party\'s identity, and how
     the data will be used, highlighting data storage and 'intent to
     store' aspects to the user. Utilising plain language and avoiding
     technical jargon can enhance understanding and minimise user
diff --git a/docs/arf.md b/docs/arf.md
index 10815c9..dcf572f 100644
--- a/docs/arf.md
+++ b/docs/arf.md
@@ -2243,8 +2243,8 @@ about the need to authenticate the Relying Party in each of the scenarios
 users of the EUDI wallets in any transaction they are involved in, from
 any risk of false authentication - without exceptions. 
 
-Note: This recommendation stems from realizing that strict requirements
-to use HSMs for all relying parties will not be practical to enforce and
+Note: This recommendation stems from realising that strict requirements
+to use HSMs for all Relying Parties will not be practical to enforce and
 will limit the usage of the wallets in cases where this high-level
 security is not necessary.
 
@@ -2434,8 +2434,8 @@ B.1.2 of \[ISO/IEC18013-5\], with the following exceptions:
 To be done.
 
 ### 7.6 Relying Party authorization
-There is a risk that relying parties may over-ask, i.e., ask a Wallet
-instance for more attributes than the Relying Party reasonably needs for
+There is a risk that Relying Parties may over-ask, i.e., ask a Wallet
+Instance for more attributes than the Relying Party reasonably needs for
 its use case. This is obviously a risk for the privacy of the user, and
 this risk must be mitigated. At least three approaches can in principle
 be used to protect the user against over-asking: the user approval
@@ -2445,13 +2445,13 @@ level.
 
 
 #### 7.6.1 User approval as a means for Relying Party authorization
-User Approval protects against over-asking by allowing the User to refuse
+User approval protects against over-asking by allowing the User to refuse
 sharing attributes that they deem unnecessary for the specific use case
 and the specific Relying Party they are dealing with. 
 
 User approval SHALL be implemented in all use cases.
 
-However,  User Approval has some limitations that MAY make it
+However, User approval has some limitations that may make it
 insufficiently effective in preventing Relying Parties from over-asking,
 as described below: 
 
@@ -2465,7 +2465,7 @@ as described below:
   Party does not actually need. Moreover, Users will be tempted to
   release all requested attributes, just to ensure they can enjoy the
   benefits of the use case.
-* Secondly, although  User Approval may prevent a misbehaving Relying
+* Secondly, although  User approval may prevent a misbehaving Relying
   Party from over-asking in individual cases, it does not provide
   authorities with a means to solve disagreements between User and
   Relying Party as to what attributes can be reasonably requested, and