feat: [RP] same device flow

.github/workflows/gh-pages.yml

@@ -4,7 +4,7 @@ name: gh-pages
 
 on:
   push:
-    branches: ["versione-corrente"]
+    branches: ["*"]
     paths-ignore:
       - README.md
       - CONTRIBUTING.md
@@ -24,7 +24,7 @@ on:
 
   # Allows you to run this workflow manually from the Actions tab
   workflow_dispatch:
-
+  
 # A workflow run is made up of one or more jobs that can run sequentially or in parallel
 jobs:
   # This workflow contains a single job called "build"
@@ -53,12 +53,12 @@ jobs:
             SUBPATH="v$TAG/" # note the trailing slash
             echo "Building for TAG: $SUBPATH"
           else
-            SUBPATH="${GITHUB_HEAD_REF}/" # note the trailing slash
+            SUBPATH=$(echo "$GITHUB_REF" | sed "s/refs\/heads\///") # "${GITHUB_HEAD_REF}/" # note the trailing slash
             echo "Building for PR: $SUBPATH"
           fi
           echo "Publishing $SUBPATH"
-          sphinx-build -b html docs/it/  html/$SUBPATHit
-          sphinx-build -b html docs/en/  html/$SUBPATHen
+          sphinx-build -b html docs/it/  html/$SUBPATH/it
+          sphinx-build -b html docs/en/  html/$SUBPATH/en
 
       # Runs a single command using the runners shell
       - name: Create GH page index

docs/en/relying-party-solution.rst

@@ -16,7 +16,7 @@ This section describes how a Relying Party may ask to a Wallet Instance the pres
 
 In this section the following flows are described:
 
-- **Same Device Flow**, where the Verifier and the Wallet Instance acts in the same device.
+- **Remote Same Device Flow**, where the Verifier and the Wallet Instance acts in the same device.
 - **Remote Cross Device Flow**, where the Verifier and the Wallet Instance acts in different devices and the Verifier is a remote Relying Party.
 
 The flows are analyzed in this chapter, taking into account security and privacy considerations.
@@ -25,20 +25,15 @@ The flows are analyzed in this chapter, taking into account security and privacy
     Relying Party and Verifier are the same entity.
 
 
-Same Device Flow
-----------------
-In the **Same Device Authorization Flow**, the User interacts with a Verifier that resides in the same device of the Wallet Instance.
-This scenario utilizes HTTP redirects to finalize the authorization phase and obtain Verifiable Presentation(s).
-
-.. note::
-
-    This flow will be described more in detail in future releases of this documentation.
+Remote Protocol Flow
+--------------------
+In the **Same Device** and **Cross Device** Authorization Flows, the User interacts with a remote Relying Party.
+This scenario requests the Verifier to provide the URL where the signed request object is available.
 
+The Verifier MUST detect the device type of the requestor (Wallet Instance), if it is a mobile device or a workstationm and activate one the supported remote flows:
 
-Remote Cross Device Flow
----------------------------
-In the **Cross Device Authorization Flow**, the User interacts with a remote Relying Party.
-This scenario requests the Verifier to show a QR Code which the User frames with their Wallet Instance.
+* In the *Same Device** flow the Verifier MUST provide a HTTP redirect (302) location to the Wallet Instance;
+* In the *Cross Device** flow the Verifier MUST provide a QR Code which the User frames with their Wallet Instance.
 
 Once the Relying Party authentication is performed by the Wallet Instance, the User gives the consent for the release of the personal data, in the form of a Verifiable Presentation.
 
@@ -58,11 +53,11 @@ Once the Relying Party authentication is performed by the Wallet Instance, the U
   * - **2**
     - The Relying Party creates an Authorization Request which contains the scopes of the request.
   * - **3**
-    - The Relying Party inserts the reference URI of the *request_uri* into a QR Code.
+    - In the **Same Device Flow** the Relying Party responses with the Request URI in the form of HTTP Location (302). In the **Cross Device Flow** the Request URI is provided in the form of a QR Code.
   * - **4**
-    - The QR Code is shown to the User that frames it.
+    - Only in **Cross Device Flow**: The QR Code is shown to the User that frames it.
   * - **5** and **6**
-    - The Wallet Instance decodes the QR Code and extracts the Request URI from the payload of the QR Code.
+    - Only in **Cross Device Flow**:  The Wallet Instance decodes the QR Code and extracts the Request URI from the payload of the QR Code.
   * - **7**
     - The Wallet Instance requests the content of the Authorization Request by invoking the Request URI, passing an Authorization DPoP HTTP Header containing the Wallet Instance Attestation and the DPoP proof HTTP Header.
   * - **8**
@@ -90,9 +85,10 @@ Once the Relying Party authentication is performed by the Wallet Instance, the U
   * - **20**
     - The Relying Party notifies the Wallet Instance that the operation ends successfully.
 
+
 Authorization Request Details
 -----------------------------
-In a Cross Device Flow, a QR Code is shown by the Relying Party to the User in order to issue the Authorization Request.
+In the Cross Device Flow, a QR Code is shown by the Relying Party to the User in order to issue the Authorization Request.
 
 The User frames the QR Code using the Wallet Instance, then grants the consent to release their attributes to the RP.
 
@@ -102,6 +98,18 @@ The payload of the QR Code is a **Base64 encoded string** based on the following
 
   eudiw://authorize?client_id=`$client_id`&request_uri=`$request_uri`
 
+In the Same Device Flow the URL is provided as described in the previous section, where the parameter **client_id** and **request_uri** are the same if the ones used in the Cross Device Flow and the only difference if in the url schema and in the removal of the Verifier's FQDN
+
+This Same Device Flow utilizes HTTP redirects to finalize the authorization phase and obtain Verifiable Presentation(s).
+
+The Relying Party produces the URL to be provided to the Wallet Instance using a HTTP 302 response (redirect), as represented in the following non-normative example:
+
+.. code:: text
+
+    HTTP/1.1 /pre-authz-endpoint Found
+    Location: https://verifier.example.org/request_uri_endpoint?
+    client_id=https%3A%2F%2Fverifier.example.org%2Fcb
+    &request_uri=https%3A%2F%2Fverifier.example.org%2Frequest_uri_endpoint
 
 Where:
 
@@ -139,7 +147,6 @@ Below follows its Base64 decoded content:
   eudiw://authorize?client_id=https://verifier.example.org&request_uri=https://verifier.example.org/request_uri
 
 
-
 Request Object Details
 ----------------------
 The following actions are made by the Wallet Instance: