improves wording

mkdocs/docs/verifier/verification-library/request-api-guide.md

@@ -103,7 +103,7 @@ In this case, the user has to provide a proof that he/she owns a credential issu
 By setting the `allowedIssuer` to `*`, the user can provide a proof of that credential issued by any issuer. Alternatively, if the verifier adds the DID of a specific issuer inside the `allowedIssuer` array, the user must provide a proof of a credential issued by that specific issuer.
 
 !!!warning "Allowed Issuers"
-    As stated above, when we use `*` in the "allowed issuers" segment (`allowedIssuers: ['*']`), we mean that we accept any entity that might have provided the credential. Even though this seems to be more practical, it may also be considered risky. Applying due diligence by **actually choosing trusted specific issuers** should be the best approach.  
+    As stated above, when we use `*` in the "allowed issuers" segment (`allowedIssuers: ['*']`), we mean that we accept any entity that might have provided the credential. Even though this seems to be convenient for testing purposes, it may also be considered risky. Applying due diligence by **actually choosing trusted specific issuers** should be the best approach. Only in rare cases, a verifier would accept any issuer, so we advise not to use `*`.  
 
 This credential contains details in its `credentialSubject` of the birthday of the receiver. In this scenario, the user has to prove that the value contained in the attribute `birthday` is less than `lt` 20000101, namely that the user was born before 01/01/2000.
 

mkdocs/docs/verifier/verification-library/verifier-set-up.md

@@ -212,7 +212,7 @@ In this example, the verifier will set up the query: "Prove that you were born b
 		```  
 
 	!!!warning "Allowed Issuers"
-    	When we use `*` in the "allowed issuers" segment (`allowedIssuers: ['*']`), we mean that we accept any entity that might have provided the credential. Even though this seems to be more practical, it may also be considered risky. Applying due diligence by **actually choosing trusted specific issuers** should be the best approach.  
+    	When we use `*` in the "allowed issuers" segment (`allowedIssuers: ['*']`), we mean that we accept any entity that might have provided the credential. Even though this seems to be convenient for testing purposes, it may also be considered risky. Applying due diligence by **actually choosing trusted specific issuers** should be the best approach. Only in rare cases, a verifier would accept any issuer, so we advise not to use `*`.   
 
 	!!!note
 		The highlighted lines are to be added only if the authentication needs to design a [query](./zk-query-language.md) for a specific proof as in the case of [Query-based Auth](./request-api-guide.md#query-based-auth). When not included, it will perform a [Basic Auth](./request-api-guide.md#basic-auth). 

mkdocs/docs/verifier/verification-library/zk-query-language.md

@@ -550,4 +550,4 @@ const proofRequest: protocol.ZKPRequest = {
 };
 ```
 !!!warning "Allowed Issuers"
-    When we use `*` in the "allowed issuers" segment (`allowedIssuers: ['*']`), we mean that we accept any entity that might have provided the credential. Even though this seems to be more practical, it may also be considered risky. Applying due diligence by **actually choosing trusted specific issuers** should be the best approach.  
+    When we use `*` in the "allowed issuers" segment (`allowedIssuers: ['*']`), we mean that we accept any entity that might have provided the credential. Even though this seems to be convenient for testing purposes, it may also be considered risky. Applying due diligence by **actually choosing trusted specific issuers** should be the best approach. Only in rare cases, a verifier would accept any issuer, so we advise not to use `*`.