Clean-up based on the suggestions from Giuseppes's code review

Co-authored-by: Giuseppe De Marco <[email protected]>

openid-4-verifiable-credential-issuance-1_0.md

@@ -884,21 +884,21 @@ When the Credential Request is invalid or unauthorized, the Credential Issuer co
 
 #### Authorization Errors {#authorization-errors}
 
-If the Credential Request does not contain an Access Token that enables issuance of a requested credential, the Credential Endpoint returns an authorization error response such as defined in section 3 of [@!RFC6750].
+If the Credential Request does not contain an Access Token that enables issuance of a requested credential, the Credential Endpoint MUST return an authorization error response as defined in section 3 of [@!RFC6750].
 
-For the errors specific to the Credential Request such as those caused by `type`, `format`, `proof`, or encryption parameters in the request, error codes parameters defined in (#credential-request-errors) SHOULD be used instead of a generic `invalid_request` parameter defined in section 3.1 of [@!RFC6750].
+For the errors specific to the Credential Request such as those caused by `type`, `format`, `proof`, or encryption parameters in the request, the error codes values defined in (#credential-request-errors) SHOULD be used instead of a generic `invalid_request` parameter defined in section 3.1 of [@!RFC6750].
 
 #### Credential Request Errors {#credential-request-errors}
 
-If the Credential Request is requesting for the issuance of a credential not supported by the Credential Endpoint, the HTTP response body uses the `application/json` media type with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response:
+If the Wallet is requesting the issuance of a credential that is not supported by the Credential Endpoint, the HTTP response MUST use the HTTP status code 400 (Bad Request) and set the content type to `application/json` with the following parameters in the response body::
 
 * `error`: REQUIRED. A key at the top level of a JSON object, the value of which SHOULD be a single ASCII [@!USASCII] error code from the following:
   * `invalid_credential_request`: The Credential Request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, or is otherwise malformed.
   * `unsupported_credential_type`: Requested credential type is not supported.
   * `unsupported_credential_format`: Requested credential format is not supported.
-  * `invalid_proof`: The `proof` in the Credential Request was invalid. For example, no key proof was provided (the `proof` field was not present); the provided key proof was not bound to a nonce provided by the Credential Issuer, etc.
+  * `invalid_proof`: The `proof` in the Credential Request is invalid. The `proof` field is not present or the provided key proof is invalid or not bound to a nonce provided by the Credential Issuer.
   * `invalid_encryption_parameters`: This error occurs when the encryption parameters in the Credential Request are either invalid or missing. In the latter case, it indicates that the Credential Issuer requires the Credential Response to be sent encrypted, but the Credential Request does not contain the necessary encryption parameters.
-* `error_description`: OPTIONAL. A key at the top level of a JSON object, the value of which MUST be a human-readable ASCII [@!USASCII] text providing additional information, used to assist the client developer in understanding the error that occurred. Values for the `error_description` parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
+* `error_description`: OPTIONAL. A key at the top level of a JSON object, whose value MUST be a human-readable ASCII [@!USASCII] text, providing any additional information used to assist the client implementers in understanding the occurred error. The values for the `error_description` parameter MUST NOT include characters outside the set `%x20-21 / %x23-5B / %x5D-7E`.
 
 The usage of these parameters takes precedence over the `invalid_request` parameter defined in (#authorization-errors), since they provide more details about the errors.
 
@@ -1089,12 +1089,12 @@ Deferred Credential Response MUST be sent using the `application/json` media typ
 
 ## Deferred Credential Error Response {#deferred-credential_error_response}
 
-When the Deferred Credential Request is invalid or the credential is not available yet, the Credential Issuer constructs the error response as defined in (#credential-error-response).
+When the Deferred Credential Request is invalid or the credential is not available yet, the Credential Issuer MUST construct the error response as defined in (#credential-error-response).
 
 The following additional error codes are specified in addition to those already defined in (#credential-request-errors):
 
-* `issuance_pending` - The credential issuance is still pending. The error response will also contain another claim `interval` determining the minimum amount of time in seconds that the Wallet SHOULD wait between requests to the Deferred Credential Endpoint.  If no value is provided, clients MUST use 5 as the default.
-* `invalid_transaction_id` - Deferred Credential Request contained an invalid `transaction_id`, i.e., it was not issued by the respective Credential Issuer or was already used to obtain the Credential.
+* `issuance_pending` - The credential issuance is still pending. The error response SHOULD also contain the `interval` member, determining the minimum amount of time in seconds that the Wallet needs to wait before providing a new request to the Deferred Credential Endpoint.  If `interval` member is missing or its value is not provided, the Wallet MUST use `5` as the default value.
+* `invalid_transaction_id` - The Deferred Credential Request contains an invalid `transaction_id`. This error occurs when the `transaction_id` was not issued by the respective Credential Issuer or it was already used to obtain the Credential.
 
 This is a non-normative example of a Deferred Credential Error Response: