From a8af165d52fe94a849879a76ffcc79e4f5316b19 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Tue, 1 Aug 2023 00:35:50 +0200 Subject: [PATCH 1/5] fix: [RP] same device uri --- docs/en/relying-party-solution.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index aa5974001..5f46c39d4 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -106,9 +106,9 @@ In the Same Device Flow the Relying Party uses a HTTP response redirect (status .. code:: text HTTP/1.1 /pre-authz-endpoint Found - Location: https://verifier.example.org/request_uri_endpoint? + Location: eudiw://authorize? client_id=https%3A%2F%2Fverifier.example.org%2Fcb - &request_uri=https%3A%2F%2Fverifier.example.org%2Frequest_uri_endpoint + &request_uri=https%3A%2F%2Fverifier.example.org%2Frequest_uri_endpoint%2Funique-session-identifier .. note:: The Same Device flow proposed in this specification is under discussion and must be considered as experimental. @@ -140,13 +140,13 @@ Below is a non-normative example of the QR Code raw payload: .. code-block:: text - ZXVkaXc6Ly9hdXRob3JpemU/Y2xpZW50X2lkPWh0dHBzOi8vdmVyaWZpZXIuZXhhbXBsZS5vcmcmcmVxdWVzdF91cmk9aHR0cHM6Ly92ZXJpZmllci5leGFtcGxlLm9yZy9yZXF1ZXN0X3VyaQ== + ZXVkaXc6Ly9hdXRob3JpemU/Y2xpZW50X2lkPWh0dHBzOi8vdmVyaWZpZXIuZXhhbXBsZS5vcmcmcmVxdWVzdF91cmk9aHR0cHM6Ly92ZXJpZmllci5leGFtcGxlLm9yZy9yZXF1ZXN0X3VyaS8kdW5pcXVlLXNlc3Npb24taWRlbnRpZmllcg== Below follows its Base64 decoded content: .. code-block:: text - eudiw://authorize?client_id=https://verifier.example.org&request_uri=https://verifier.example.org/request_uri + eudiw://authorize?client_id=https://verifier.example.org&request_uri=https://verifier.example.org/request_uri/$unique-session-identifier Request Object Details From f6e75a9ba0e5bcff547d0f76876adae12e59dc19 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Wed, 2 Aug 2023 17:48:31 +0200 Subject: [PATCH 2/5] feat: implementation and security consideration for securing sessions in the cross device flow --- docs/en/relying-party-solution.rst | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 5f46c39d4..95a42817d 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -140,13 +140,27 @@ Below is a non-normative example of the QR Code raw payload: .. code-block:: text - ZXVkaXc6Ly9hdXRob3JpemU/Y2xpZW50X2lkPWh0dHBzOi8vdmVyaWZpZXIuZXhhbXBsZS5vcmcmcmVxdWVzdF91cmk9aHR0cHM6Ly92ZXJpZmllci5leGFtcGxlLm9yZy9yZXF1ZXN0X3VyaS8kdW5pcXVlLXNlc3Npb24taWRlbnRpZmllcg== + ZXVkaXc6Ly9hdXRob3JpemU/Y2xpZW50X2lkPWh0dHBzOi8vdmVyaWZpZXIuZXhhbXBsZS5vcmcmcmVxdWVzdF91cmk9aHR0cHM6Ly92ZXJpZmllci5leGFtcGxlLm9yZy9yZXF1ZXN0X3VyaS8= Below follows its Base64 decoded content: .. code-block:: text - eudiw://authorize?client_id=https://verifier.example.org&request_uri=https://verifier.example.org/request_uri/$unique-session-identifier + eudiw://authorize?client_id=https://verifier.example.org&request_uri=https://verifier.example.org/request_uri + +Cross Device Security Considerations +------------------------------------ + +When the flow is Cross Device, the user-agent needs to check the session status to an endpoint made available by Relying Party and specialized for this scope. This check MAY be implemented in the page that shows the QRCode, then the user-agent checks the status with a polling strategy in seconds or with 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. + +The Relyng Party MUST bind the request of the user-agent, with a Secured and Httponly session cookie, with the issued request (using the ``state`` parameter). The status returned by this specialized endpoint MAY return 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. +* **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. Request Object Details From b765c1e7d24ba19c1e42236b7ff67caaf658b0e2 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Wed, 2 Aug 2023 17:52:06 +0200 Subject: [PATCH 3/5] chore: cleanup --- docs/en/relying-party-solution.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 95a42817d..0b495f127 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -98,7 +98,7 @@ 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 parameter **client_id** and **request_uri** are the same if the ones used in the Cross Device Flow with the only difference about the url schema and the removal of the Verifier's FQDN from the URL. +In the Same Device Flow the parameter **client_id** and **request_uri** are the same if the ones used in the Cross Device Flow with the only difference about the url schema and the removal of the Verifier's FQDN from the URL. In the Same Device Flow the Relying Party uses a HTTP response redirect (status code 302) to give to the Wallet Instance the resource where the request object is available for download, as represented in the following non-normative example: @@ -108,7 +108,7 @@ In the Same Device Flow the Relying Party uses a HTTP response redirect (status HTTP/1.1 /pre-authz-endpoint Found Location: eudiw://authorize? client_id=https%3A%2F%2Fverifier.example.org%2Fcb - &request_uri=https%3A%2F%2Fverifier.example.org%2Frequest_uri_endpoint%2Funique-session-identifier + &request_uri=https%3A%2F%2Fverifier.example.org%2Frequest_uri_endpoint .. note:: The Same Device flow proposed in this specification is under discussion and must be considered as experimental. From 873d0e38621c6756eab16619d064c928907d538c Mon Sep 17 00:00:00 2001 From: peppelinux Date: Wed, 2 Aug 2023 18:01:09 +0200 Subject: [PATCH 4/5] feat: added non nroamtive example for RP cross device sec cons --- docs/en/relying-party-solution.rst | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 0b495f127..fa9d5050d 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -148,20 +148,28 @@ Below follows its Base64 decoded content: eudiw://authorize?client_id=https://verifier.example.org&request_uri=https://verifier.example.org/request_uri -Cross Device Security Considerations ------------------------------------- +Cross Device Flow Security Considerations +----------------------------------------- -When the flow is Cross Device, the user-agent needs to check the session status to an endpoint made available by Relying Party and specialized for this scope. This check MAY be implemented in the page that shows the QRCode, then the user-agent checks the status with a polling strategy in seconds or with a push strategy (eg: web socket). +When the flow is Cross Device, the user-agent needs to check the session status to an endpoint made available by Relying Party and specialized for this scope. 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 with 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. -The Relyng Party MUST bind the request of the user-agent, with a Secured and Httponly session cookie, with the issued request (using the ``state`` parameter). The status returned by this specialized endpoint MAY return the HTTP status codes listed below: +The Relyng Party MUST bind the request of the user-agent, with a Secured and Httponly session cookie, with the issued request (using the ``state`` parameter). 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. * **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. +Below a non normative example of how the HTTP Request to this specialized endpoint, that MUST carry the session cookie to be updated following the status of the authentication: + +.. code:: + + GET /session-state?state=3be39b69-6ac1-41aa-921b-3e6c07ddcb03 + HTTP/1.1 + HOST: verifier.example.org + Request Object Details ---------------------- From 6a6b2116ff169bff803e3d51cf8ff5a24d2da95f Mon Sep 17 00:00:00 2001 From: peppelinux Date: Thu, 3 Aug 2023 14:28:39 +0200 Subject: [PATCH 5/5] fix: same device universal link and random parameter valur for request_uri endpoint --- docs/en/relying-party-solution.rst | 35 +++++++++++++++++------------- images/verifier_qr_code.svg | 12 ++-------- 2 files changed, 22 insertions(+), 25 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index fa9d5050d..541c424ae 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -88,9 +88,10 @@ Once the Relying Party authentication is performed by the Wallet Instance, the U Authorization Request Details ----------------------------- -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. +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 Relying Party. The payload of the QR Code is a **Base64 encoded string** based on the following format: @@ -98,17 +99,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 parameter **client_id** and **request_uri** are the same if the ones used in the Cross Device Flow with the only difference about the url schema and the removal of the Verifier's FQDN from the URL. +The `request_uri` parameter MUST contain the endpoint where the signed presentation request object is available for download. The value corresponding to that endpoint MUST be randomized, according to `RFC 9101, +The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) `_ Section 5.2.1. -In the Same Device Flow the Relying Party uses a HTTP response redirect (status code 302) to give to the Wallet Instance the resource where the request object is available for download, as represented in the following non-normative example: +In the **Same Device Flow** the Relying Party uses a HTTP response redirect (status code 302) as represented in the following non-normative example: .. code:: text HTTP/1.1 /pre-authz-endpoint Found - Location: eudiw://authorize? + Location: https://wallet-providers.eudi.wallet.gov.it? client_id=https%3A%2F%2Fverifier.example.org%2Fcb - &request_uri=https%3A%2F%2Fverifier.example.org%2Frequest_uri_endpoint + &request_uri=https%3A%2F%2Fverifier.example.org%2Frequest_uri%3Fid%3Drandom-value .. note:: The Same Device flow proposed in this specification is under discussion and must be considered as experimental. @@ -122,9 +124,9 @@ Where: * - **Name** - **Description** * - **client_id** - - Client unique identifier of the Verifier. + - Client unique identifier of the Relying Party. * - **request_uri** - - The Verifier request URI used by the Wallet Instance to retrieve the Request Object. + - The Relying Partyrequest URI used by the Wallet Instance to retrieve the Request Object, extended with a random value passed by URL parameter. .. note:: The *error correction level* chosen for the QR Code MUST be Q (Quartily - up to 25%), since it offers a good balance between error correction capability and data density/space. This level of quality and error correction allow the QR Code to remain readable even if it is damaged or partially obscured. @@ -146,23 +148,26 @@ Below follows its Base64 decoded content: .. code-block:: text - eudiw://authorize?client_id=https://verifier.example.org&request_uri=https://verifier.example.org/request_uri + eudiw://authorize?client_id=https://verifier.example.org&request_uri=https%3A%2F%2Fverifier.example.org%2Frequest_uri%3Fid%3Drandom-value + -Cross Device Flow Security Considerations ------------------------------------------ +Cross Device Flow Status Checks and Security +-------------------------------------------- -When the flow is Cross Device, the user-agent needs to check the session status to an endpoint made available by Relying Party and specialized for this scope. 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 with a push strategy (eg: web socket). +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). -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 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. -The Relyng Party MUST bind the request of the user-agent, with a Secured and Httponly session cookie, with the issued request (using the ``state`` parameter). The HTTP response returned by this specialized endpoint MAY contain the HTTP status codes listed below: +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. * **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. -Below a non normative example of how the HTTP Request to this specialized endpoint, that MUST carry the session cookie to be updated following the status of the authentication: +The request to the endpoint MUST carry within its HTTP headers the session cookie, to be then updated on occurrence following the status of the authentication if this is successful. + +Below a non-normative example of the HTTP Request to this specialized endpoint: .. code:: diff --git a/images/verifier_qr_code.svg b/images/verifier_qr_code.svg index f525432cc..091e211bc 100644 --- a/images/verifier_qr_code.svg +++ b/images/verifier_qr_code.svg @@ -1,10 +1,2 @@ - - - - QR Code - ZXVkaXc6Ly9hdXRob3JpemU/Y2xpZW50X2lkPWh0dHBzOi8vdmVyaWZpZXIuZXhhbXBsZS5vcmcmcmVxdWVzdF91cmk9aHR0cHM6Ly92ZXJpZmllci5leGFtcGxlLm9yZy9yZXF1ZXN0X3VyaQ== - - - - - + + \ No newline at end of file