fix: RP seq, editorials

docs/en/relying-party-solution.rst

@@ -28,10 +28,11 @@ Remote Protocol Flow
 In this scenario the Relying Party provides the URL where the signed presentation request object is available for download.
 
 Depending on whether the Relying Party client is on a mobile device or a workstation, it must activate one of the supported remote flows:
+
 * **Same Device**, the Relying Party MUST provide a HTTP redirect (302) location to the Wallet Instance;
 * **Cross Device**, the Relying Party MUST provide a QR Code which the User frames with their Wallet Instance.
 
-Once the Wallet Instances establishes the trust with the Relying Party, the User gives the consent for the release of the personal data, in the form of a Verifiable Presentation.
+Once the Wallet Instance establishes the trust with the Relying Party, the User gives the consent for the release of the personal data, in the form of a Verifiable Presentation.
 
 Below a sequence diagrams that summarizes the interactions between all the involved parties.
 
@@ -78,7 +79,7 @@ The details of each step is described in the previous picture are described in t
 Authorization Request Details
 -----------------------------
 
-The Relying Party creates a signed request object, then gives to the Wallet Instance the request URI that points to the resource where the signed request object MUST be available for download. The URL parameters contained in the Relying Party response, containing the request URI, are described in the Table below.
+The Relying Party creates a signed request object, then gives it to the Wallet Instance through a HTTP URL (request URI) that points to the resource where the signed request object MUST be available for download. The URL parameters contained in the Relying Party response, containing the request URI, are described in the Table below.
 
 .. list-table::
   :widths: 25 50
@@ -87,18 +88,17 @@ The Relying Party creates a signed request object, then gives to the Wallet Inst
   * - **Name**
     - **Description**
   * - **client_id**
-    - Client unique identifier of the Relying Party.
+    - Unique identifier of the Relying Party.
   * - **request_uri**
-    - The Relying Party request URI used by the Wallet Instance to retrieve the signed request object. The URI value is intentionally extended with a random value that uniquely identifies the transaction.
+    - The HTTP URL used by the Wallet Instance to retrieve the signed request object from the Relying Party. The URL is intentionally extended with a random value that uniquely identifies the transaction.
 
 Below a non-normative example of the response containing the required parameters previously described.
 
 .. code-block:: javascript
 
   eudiw://authorize?client_id=`$client_id`&request_uri=`$request_uri`
 
-The value corresponding to the `request_uri` endpoint MUST be randomized, according to `RFC 9101,
-The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) <https://www.rfc-editor.org/rfc/rfc9101.html#section-5.2.1>`_ Section 5.2.1.
+The value corresponding to the `request_uri` endpoint MUST be randomized, according to `RFC 9101, The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) <https://www.rfc-editor.org/rfc/rfc9101.html#section-5.2.1>`_ Section 5.2.1.
 
 
 In the **Same Device Flow** the Relying Party uses a HTTP response redirect (status code 302) as represented in the following non-normative example:
@@ -138,13 +138,13 @@ The decoded content of the previous Base64 value is represented below:
 Cross Device Flow Status Checks and Security
 --------------------------------------------
 
-When the flow is Cross Device, the user-agent needs to check the session status to the endpoint specialized for this scope and made available by Relying Party. This check MAY be implemented in the form of JavaScript code, within the page that shows the QRCode, then the user-agent checks the status with a polling strategy in seconds or a push strategy (eg: web socket).
+When the flow is Cross Device, the user-agent needs to check the session status to the endpoint made available by Relying Party (status endpoint). This check MAY be implemented in the form of JavaScript code, within the page that shows the QRCode, then the user-agent checks the status with a polling strategy in seconds or a push strategy (eg: web socket).
 
-Since the QRcode page and the specialized endpoint are implemented by the Relying Party, it is under its responsability the implementation details of this solution, since it is related to the Relying Party's internal API.
+Since the QRcode page and the status endpoint are implemented by the Relying Party, it is under its responsability the implementation details of this solution, since it is related to the Relying Party's internal API.
 
 The Relyng Party MUST bind the request of the user-agent, with a Secured and Httponly session cookie, with the issued request (using the ``random-value`` parameter within the ``request_uri`` value). The HTTP response returned by this specialized endpoint MAY contain the HTTP status codes listed below:
 
-* **201 Created**. The signed request object was issued by the Relying Party that waits to be downloaded by the Wallet Instance at the **request_uri** endpoint.
+* **204 No Content**. The signed request object was issued by the Relying Party that waits to be downloaded by the Wallet Instance at the **request_uri** endpoint.
 * **202 Accepted**. This response is given when the signed request object was obtained by the Wallet Instance.
 * **302 Found**. The Wallet Instance has sent the presentation to the Relying Party's  **redirect_uri** endpoint and the User authentication is successful. The Relying Party updates the session cookie allowing the user-agent to access to the protected resource. The ``Location`` within the HTTP Response allows the user-agent to leave the QRCode page.
 * **403 Forbidden**. The Wallet Instance or its User have rejected the request, or the request is expired. The QRCode page SHOULD be updated with an error message.