Apply suggestions from code review

Implement review suggestions

Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

Author: martijnharing

openid-4-verifiable-presentations-1_0.md

@@ -320,7 +320,7 @@ The following is a non-normative example of a transaction data content, after ba
 : OPTIONAL. A non-empty array of attestations about the Verifier relevant to the Credential Request. These attestations MAY include Verifier metadata, policies, trust status, or authorizations. Attestations are intended to support authorization decisions, inform Wallet policy enforcement, or enrich the End-User consent dialog. Each object has the following structure:
 
     * `format`: REQUIRED. A string that identifies the format of the attestation and how it is encoded. Ecosystems SHOULD use collision-resistant identifiers. Further processing of the attestation is determined by the type of the attestation, which is specified in a format-specific way. 
-    * `data`: REQUIRED. An object or string containing an attestation (e.g. a JWT). The payload structure is defined on a per format level. It is at the discretion of the Wallet (for example based on policies from ecosystems, profiles, issuers or Holders) whether it uses the information from `verifier_attestations`. If the Wallet uses information from `verifier_attestations`, the Wallet MUST validate the signature and ensure binding.
+    * `data`: REQUIRED. An object or string containing an attestation (e.g. a JWT). The payload structure is defined on a per format level. It is at the discretion of the Wallet whether it uses the information from `verifier_attestations`. Factors that influence such Wallet's decision include, but are not limited to, trust framework the wallet supports, specific policies defined by the Issuers or ecosystem, and profiles of this specification. If the Wallet uses information from `verifier_attestations`, the Wallet MUST validate the signature and ensure binding.
     * `credential_ids`: OPTIONAL. A non-empty array of strings each referencing a Credential requested by the Verifier for which the attestation is relevant. Each string matches the `id` field in a DCQL Credential Query. If omitted, the attestation is relevant to all requested credentials.
 
 See (#verifier-attestations) for more details.
@@ -561,7 +561,7 @@ From this definition, it follows that pre-registered clients MUST NOT contain a
 
 This specification defines the following Client Identifier Prefixes, followed by the examples where applicable. 
 
-In case of using OpenID4VP over DC API as defined in (#dc_api) it is at the discretion of the Wallet (for example based on policies from ecosystems, profiles, issuers or Holders) whether it uses the information from a client identifier. If the Wallet uses information from a client identifier, the Wallet must perform all the verification requirements for that client identifier as defined below. If it doesn't use the information from a client identifier, the Wallet does not need to implement the verification requirements for that client identifier as defined below.
+In case of using OpenID4VP over DC API, as defined in (#dc_api), it is at the discretion of the Wallet whether it validates the signature on the Request Object following the processing rules defined by a relevant Client Identifier Prefix. Factors that influence Wallet's decision include, but are not limited to, trust framework the wallet supports, specific policies defined by the Issuers or ecosystem, and profiles of this specification.
 
 * `redirect_uri`: This prefix value indicates that the original Client Identifier part (without the prefix `redirect_uri:`) is the Verifier's Redirect URI (or Response URI when Response Mode `direct_post` is used). The Verifier MAY omit the `redirect_uri` Authorization Request parameter (or `response_uri` when Response Mode `direct_post` is used). All Verifier metadata parameters MUST be passed using the `client_metadata` parameter defined in (#new_parameters). An example Client Identifier value is `redirect_uri:https://client.example.org/cb`. Requests using the `redirect_uri` Client Identifier Prefix cannot be signed because there is no method for the Wallet to obtain a trusted key for verification. Therefore, implementations requiring signed requests cannot use the `redirect_uri` Client Identifier Prefix.