Apply suggestions from code review

Co-authored-by: fmarino-ipzs <[email protected]>

docs/en/pid-eaa-issuance.rst

@@ -63,7 +63,7 @@ The :numref:`fig_High-Level-Flow-ITWallet-QEAA-Issuance` shows a general archite
 
 Below the description of the most relevant operations involved in the (Q)EAA issuance:
 
-    1. **Obtaining the trusted (Q)EAA Issuer**: the Wallet Instance discovers the trusted (Q)EAA Issuer ufing the Federaiton API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), then inspects the metadata looking for the credential capabilities. 
+    1. **Obtaining the trusted (Q)EAA Issuer**: the Wallet Instance discovers the trusted (Q)EAA Issuer using the Federation API (e.g.: using the Subordinate Listing Endpoint of the Trust Anchor and its Intermediates), then inspects the metadata looking for the credential capabilities. 
     2. **Obtaining of (Q)EAA Issuer metadata**: the Wallet Instance establishes the trust to the (Q)EAA Issuer according to the Trust Model, obtaining the Metadata that discloses the formats of the (Q)EAA, the algorithms supported, and any other parameter required for interoperability needs.
     3. **(Q)EAA request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] <https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html>`_ the Wallet Instance requests a (Q)EAA to the (Q)EAA Issuer. A fresh key pairs is generated by the Wallet Instance, the public key is used by (Q)EAA Issuer for the Holder Key Binding. The (Q)EAA Issuer checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider.
     4. **End-user authentication**: the (Q)EAA Issuer, acting as an Relying Party, authenticates the User with the PID. 
@@ -238,7 +238,7 @@ The JWS payload of the request object is represented below:
 
 .. note::
 
-    **PID Credential Schema and Status registration:** The PID/(Q)EAA Issuer MUST register all the issued credentials for their later revocation. 
+    **PID/(Q)EAA Credential Schema and Status registration:** The PID/(Q)EAA Issuer MUST register all the issued credentials for their later revocation. 
 
 .. code-block:: http
 
@@ -672,7 +672,7 @@ Credential Request
 
 The Wallet Instance when requests the PID/(Q)EAA to the PID/(Q)EAA Credential endpoint, MUST use the following parameters in the entity-body of the HTTP POST request, using the `application/json` media type.
 
-The Credential endpoint MUST accept and validate the *DPoP proof* sent in the DPoP field of the HTTP Header based on the steps defined in Section 4.3 of [DPoP-draft16]. The *DPoP proof* in addition to the values that are defined in the Token Endpoint section MUST contain the following claim:
+The Credential Endpoint MUST accept and validate the *DPoP proof* sent in the DPoP field of the HTTP Header based on the steps defined in Section 4.3 of [DPoP-draft16]. The *DPoP proof* in addition to the values that are defined in the Token Endpoint section MUST contain the following claim:
 
   - **ath**: hash of the Access Token. The value MUST be the result of a base64url encoding (as defined in Section 2 of :rfc:`7515`) the SHA-256 hash of the ASCII encoding of the associated Access Token's value.
 
@@ -763,7 +763,7 @@ Credential Response to the Wallet Instance MUST be sent using `application/json`
     - Format of the Credential to be issued. This MUST be set to `vc+sd-jwt` when the credential type is SD-JWT.
     - `[OIDC4VCI. Draft 13] <https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html>`_.
   * - **credential**
-    - Contains the issued PID/(Q)EAA. When the credential type is SD-JWT, it MUST be an SD-JWT JSON Object (see Section :ref:`PID/(Q)EAA Data Model <pid_eaa_data_model.rst>`).
+    - Contains the issued PID/(Q)EAA. When the credential type is SD-JWT, it MUST be an `SD-JWT`_ JSON Object (see Section :ref:`PID/(Q)EAA Data Model <pid_eaa_data_model.rst>`).
     - Appendix E in `[OIDC4VCI. Draft 13] <https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html>`_.
   * - **c_nonce**
     - JSON string containing a ``nonce`` value to be used to create a *proof of possession* of the key material when requesting a further credential or for the renewal of a credential.