From 41929defeb29be657660e0e39df1bf9fb8fdea80 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Mon, 24 Jul 2023 14:36:59 +0200 Subject: [PATCH 1/7] feat: [RP] same device flow --- docs/en/relying-party-solution.rst | 31 +++++++++++++++++++----------- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index a35bf3e4a..7c693de61 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -25,16 +25,6 @@ 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 Cross Device Flow --------------------------- In the **Cross Device Authorization Flow**, the User interacts with a remote Relying Party. @@ -90,9 +80,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 +93,8 @@ 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 + Where: @@ -139,6 +132,22 @@ Below follows its Base64 decoded content: eudiw://authorize?client_id=https://verifier.example.org&request_uri=https://verifier.example.org/request_uri +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). + +The flow is identical to the cross device with the only replacement of the steps relating to the use of the QRCode, i.e. steps number **3**, **4**, **5** and **6**, which are replaced by a single step described below. + +The Relying Party produces a URL similar to the one contained in the QRCode produced in the Cross Device Flow, then provides it to the Wallet Instance via an HTTP 302 response (redirect), 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 + Request Object Details ---------------------- From 6cd873150d938903aa9ab84b98d873606f04d173 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 24 Jul 2023 14:49:47 +0200 Subject: [PATCH 2/7] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 1e3aa36c0..58a5c934f 100644 --- a/.github/workflows/gh-pages.yml +++ b/.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 From eff780ef027eaf27eeed7d79ebe3018cb1dc957f Mon Sep 17 00:00:00 2001 From: peppelinux Date: Mon, 24 Jul 2023 15:04:45 +0200 Subject: [PATCH 3/7] feat: [RP] same device flow improved --- docs/en/relying-party-solution.rst | 48 ++++++++++++------------ images/cross_device_auth_seq_diagram.svg | 2 +- 2 files changed, 24 insertions(+), 26 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 7c693de61..2815a0a45 100644 --- a/docs/en/relying-party-solution.rst +++ b/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,10 +25,15 @@ The flows are analyzed in this chapter, taking into account security and privacy Relying Party and Verifier are the same entity. -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. +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: + +* 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. @@ -48,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** @@ -95,6 +100,16 @@ The payload of the QR Code is a **Base64 encoded string** based on the following 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: @@ -132,23 +147,6 @@ Below follows its Base64 decoded content: eudiw://authorize?client_id=https://verifier.example.org&request_uri=https://verifier.example.org/request_uri -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). - -The flow is identical to the cross device with the only replacement of the steps relating to the use of the QRCode, i.e. steps number **3**, **4**, **5** and **6**, which are replaced by a single step described below. - -The Relying Party produces a URL similar to the one contained in the QRCode produced in the Cross Device Flow, then provides it to the Wallet Instance via an HTTP 302 response (redirect), 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 - - Request Object Details ---------------------- The following actions are made by the Wallet Instance: diff --git a/images/cross_device_auth_seq_diagram.svg b/images/cross_device_auth_seq_diagram.svg index 2ac670e5a..078c544b3 100644 --- a/images/cross_device_auth_seq_diagram.svg +++ b/images/cross_device_auth_seq_diagram.svg @@ -1,2 +1,2 @@ -UserUserWallet InstanceWallet InstanceRelying PartyRelying PartyAuthentication1Request Protected Resource2Create Authorization Request3Create QR Code4Show QRCode5Scan QR Code6Extract Request URIfrom QR Code7GET Request Objectby Request URIwith Wallet Instance Attestationas DPoP token8Attest Wallet Instance Trust9Request Object10Attest Relying Party Trust11Verify Relying Party Metadata12Validate JWT Signature13Validate Requested VP(s)14Request for consent15Confirmed16POST Authorization Responsewith vp_token17Attest Credential Issuer Trust18Validate JWT Signature19Process the credential20Process Authorization ResponseProcess phase requires to:- validate integrity, authenticity, and holder binding of VP(s)- ensure all VP(s) are linked with Verifier- ensure all VP(s) are linked with current session nonce- ensure all VC(s) requested is present21OK \ No newline at end of file +UserUserWallet InstanceWallet InstanceRelying PartyRelying PartyAuthentication1Request Protected Resource2Create Authorization Request3Create request_uri resource4QRCode OR HTTP Redirect (302) with the request_uriCross Device only5Scan QR Code6Extract Request URIfrom QR Code7GET Request Objectby Request URIwith Wallet Instance Attestationas DPoP token8Attest Wallet Instance Trust9Request Object10Attest Relying Party Trust11Verify Relying Party Metadata12Validate JWT Signature13Validate Requested VP(s)14Request for consent15Confirmed16POST Authorization Responsewith vp_token17Attest Credential Issuer Trust18Validate JWT Signature19Process the credential20Process Authorization ResponseProcess phase requires to:- validate integrity, authenticity, and holder binding of VP(s)- ensure all VP(s) are linked with Verifier- ensure all VP(s) are linked with current session nonce- ensure all VC(s) requested is present21OK \ No newline at end of file From 86926f170632e8b5dc69354a4d799cac22824b44 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Wed, 26 Jul 2023 12:59:42 +0200 Subject: [PATCH 4/7] Apply suggestions from code review --- docs/en/relying-party-solution.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 2815a0a45..9c17cb4a2 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -98,11 +98,10 @@ 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 +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. -This Same Device Flow utilizes HTTP redirects to finalize the authorization phase and obtain Verifiable Presentation(s). +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: -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 From 05b550a2566d212d5b502b2cb9071d3964013cda Mon Sep 17 00:00:00 2001 From: peppelinux Date: Fri, 28 Jul 2023 12:35:23 +0200 Subject: [PATCH 5/7] fix: SVG link, missing nonce in the presentation response, added table for the VP parameters --- docs/en/relying-party-solution.rst | 34 ++++++++++++++++++++---- images/cross_device_auth_seq_diagram.svg | 2 +- 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 2815a0a45..eb15f1896 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -40,7 +40,7 @@ Once the Relying Party authentication is performed by the Wallet Instance, the U .. image:: ../../images/cross_device_auth_seq_diagram.svg :align: center - :target: //www.plantuml.com/plantuml/png/ZPF1Rjf048Rl-nIZd5gfUG4agaGqgcXLuG99Bf6gnJlWRSmidPsrIv--QpjhOn1IRlZtDpyp_upll6YMi2-L3k8ex3V8IXsYPdDxq2Hmy-YHRq1x26FzMPSb2imfMb2EBLAFaIMMHqixoA9uR84AbPfEuJv8WHH1BTOHm7Ig0jn-ZgydiCG_0Rr0naum5pHHyIvmZahdOYijsDXKc0fcZ55hFHtRVwrbShd4VYvXvaoghoUmAbmTrLOqUFeN_UzQgJhHkQRaqOiFVuKZtBV-k9o_q9RTVY1J5ryVrZsssFp6MFL2c-DfQHHgAmMS1Gpt8f5enuk8zl0bSnc8UqMwaanNSM6qvl2MJDV-k9zn26d6v3LQQUVK8q_8TdiyGtwWQAD53vGkRHGGlZslOMLtf2KmNhnENQ61f-o3_zW1OUXswnXoHnv9Xl632ccgcQEjvJsQqu72i8biiLfV78q_D8unNcXNK1r-lIFV6QD14gjBc7iVa5F22Rmsym1ax7Bq7gH0o7kxI-1AmugS8BWAUGGV2kqHE0Pc6QEvcyJ9Rg5AtLWItB6LuoVGwOlidiX0uKg331jBfjccstPxQ0oGV624U5QT1Ze-bPPUqRIvTPTWaTy5vu4PIS2ZzyrGv2Z7yyfPKydzITWu7AD7EhtZnNTbyFIZFJlbEoGJzkL_ + :target: //www.plantuml.com/plantuml/png/ZPDFQnin4CNl-XH3JWaqKDfRm2N13MrQYhUEarm2GLwDRJNhaJiQhUj--iwkkki_nf3RUlJJqvkPv-iebYKjAsEJ14hBAR8nAwtvqgyi2PmzHEGpi17IVlt9LXKAt95AK8ajijv7nbXjFCsXqEAc1Meq9i7b9_suWZ7-JXW52Ww2fQ3JIWo9IuK60xX9ia1IDIi-4C1WO6mflhQ2ZKwDdSwGKMij7zZ_RV5E_1ZZVF2Is0DtxsLgVGK_nyFW44PZ-3gP5AhYFAitEF_u_iC5hBqiG1Px8iRXhgt-UstCd4DQwRiXHlYCjIyH0bKRiywFmNrfIL-4vic-UFj7M4NwwJoCxvvfnc7PaqZEPBnfwyljf6T7qr-DsMUQRdRlQw5rVh0ok15HefsN8bPD5g402Qz89qQTRnm9JJZz7tNkOT_FmOHoextMNaYoKeyy8llPvW3vWMAT5RkbREMrWF3jQGBtVavM4kFHSUSA7JmMv_4Y0sdhTXOOoa0HIRRj9vEwheQ1PfwNw7ORIjjD5AFxoL4AuwfHrF7cyDIhbpVCTyZeckZR2kvYJCZzX3DuikSjK70eCSOshMKlTmoSC6me24AeaVVWrSB6d7xFgEBXIZkxXBfpuqbmpbusxy1sVz_yYnmiGkMGOUh9DTiCixo7HW0f9aRGMEKQM4QeFBsYQ-UMa-2HtmINYHb98AhbfYaALEBXpM5pa_j8U6sECIBjvdZqVNVLQsCEedoDvDAo-WS0 .. list-table:: :widths: 50 50 @@ -151,7 +151,7 @@ Request Object Details ---------------------- The following actions are made by the Wallet Instance: -- scan the QR Code; +- scan the QR Code (Cross Device only); - extract from the payload the ``request_uri`` parameter; - invoke the retrieved URI; - provide in the request its Wallet instance Attestation, using `DPOP`_ to proof the legitimate possession of it; @@ -410,6 +410,7 @@ Below is a non-normative example of the decrypted JSON ``response`` content: { "state": "3be39b69-6ac1-41aa-921b-3e6c07ddcb03", + "nonce": "2c128e4d-fc91-4cd3-86b8-18bdea0988cb" "vp_token": "eyJhbGciOiJFUzI1NiIs...PT0iXX0", "presentation_submission": { "definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653", @@ -424,7 +425,7 @@ Below is a non-normative example of the decrypted JSON ``response`` content: } } -Where the following parameters are used: +Where the following parameters are used: .. list-table:: :widths: 25 50 @@ -437,7 +438,9 @@ Where the following parameters are used: * - **presentation_submission** - JSON Object contains mappings between the requested Verifiable Credentials and where to find them within the returned VP Token. * - **state** - - Unique identifier provided by the Verifier inside the Authorization Request + - Unique identifier provided by the Verifier within the Authorization Request. + * - **nonce** + - Nonce provided by the Verifier within the Authorization Request. Below is a non-normative example of the ``vp_token`` decoded content, represented in the form of JWS header and payload, separated by a period: @@ -456,10 +459,31 @@ Below is a non-normative example of the ``vp_token`` decoded content, represente "aud": "https://verifier.example.org/callback", "iat": 1541493724, "exp": 1573029723, - "nonce": "n-0S6_WzA2Mj", + "nonce": "2c128e4d-fc91-4cd3-86b8-18bdea0988cb" "vp": "~~~...~" } +Where the following parameters are used: + +.. list-table:: + :widths: 25 50 + :header-rows: 1 + + * - **Name** + - **Description** + * - **vp** + - The digital credential in its original state. The public key contained in the digital credential MUST be used to verify the entire VP JWS as Proof of Possession of the private key which the public part is carried in the digital credential (Holder Key Binding). + * - **jti** + - JWS Unique identifier. + * - **iat** + - Unix timestamp of the issuance datetime. + * - **exp** + - Unix timestamp beyond which the presentation of the digital credential will no longer be considered valid. + * - **aud** + - Audience of the VP, corresponding to the ``redirect_uri`` within the Authorization request issued by the Relying Party. + * - **nonce** + - Nonce provided by the Verifier within the Authorization Request. + Relying Party Entity Configuration --------------------------------------------- According to the `Trust Model`_ section, the Verifier is a Federation Entity and MUST expose a .well-known endpoint containing its Entity Configuration. diff --git a/images/cross_device_auth_seq_diagram.svg b/images/cross_device_auth_seq_diagram.svg index 078c544b3..1655856e4 100644 --- a/images/cross_device_auth_seq_diagram.svg +++ b/images/cross_device_auth_seq_diagram.svg @@ -1,2 +1,2 @@ -UserUserWallet InstanceWallet InstanceRelying PartyRelying PartyAuthentication1Request Protected Resource2Create Authorization Request3Create request_uri resource4QRCode OR HTTP Redirect (302) with the request_uriCross Device only5Scan QR Code6Extract Request URIfrom QR Code7GET Request Objectby Request URIwith Wallet Instance Attestationas DPoP token8Attest Wallet Instance Trust9Request Object10Attest Relying Party Trust11Verify Relying Party Metadata12Validate JWT Signature13Validate Requested VP(s)14Request for consent15Confirmed16POST Authorization Responsewith vp_token17Attest Credential Issuer Trust18Validate JWT Signature19Process the credential20Process Authorization ResponseProcess phase requires to:- validate integrity, authenticity, and holder binding of VP(s)- ensure all VP(s) are linked with Verifier- ensure all VP(s) are linked with current session nonce- ensure all VC(s) requested is present21OK \ No newline at end of file +UserUserWallet InstanceWallet InstanceRelying PartyRelying Party1Request Protected ResourceAuthentication2Create Authorization Request3Create request_uri resource4QRCode OR HTTP Redirect (302) with the request_uriCross Device only5Scan QR Code6Extract Request URIfrom QR Code7GET Request Objectby Request URIwith Wallet Instance Attestationas DPoP token8Attest Wallet Instance Trust9Request Object10Attest Relying Party Trust11Verify Relying Party Metadata12Validate JWT Signature13Validate Requested VP(s)14Request for consent15Confirmed16POST Authorization Responsewith vp_token17Attest Credential Issuer Trust18Validate JWT Signature19Process the credential20Process Authorization ResponseProcess phase requires to:- validate integrity, authenticity, and holder binding of VP(s)- ensure all VP(s) are linked with Verifier- ensure all VP(s) are linked with current session nonce- ensure all VC(s) requested is present21OK \ No newline at end of file From 80881b7f3a2f12e68f5c4d2142cc60ad30f734a9 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Fri, 28 Jul 2023 14:35:01 +0200 Subject: [PATCH 6/7] fix: nonce goes just in the vp token and not in the authorization response --- docs/en/relying-party-solution.rst | 3 --- 1 file changed, 3 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 179143b73..0c37ba232 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -409,7 +409,6 @@ Below is a non-normative example of the decrypted JSON ``response`` content: { "state": "3be39b69-6ac1-41aa-921b-3e6c07ddcb03", - "nonce": "2c128e4d-fc91-4cd3-86b8-18bdea0988cb" "vp_token": "eyJhbGciOiJFUzI1NiIs...PT0iXX0", "presentation_submission": { "definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653", @@ -438,8 +437,6 @@ Where the following parameters are used: - JSON Object contains mappings between the requested Verifiable Credentials and where to find them within the returned VP Token. * - **state** - Unique identifier provided by the Verifier within the Authorization Request. - * - **nonce** - - Nonce provided by the Verifier within the Authorization Request. Below is a non-normative example of the ``vp_token`` decoded content, represented in the form of JWS header and payload, separated by a period: From 50721aabddb616c8e0edcc7726bd4da7abd1c59d Mon Sep 17 00:00:00 2001 From: peppelinux Date: Fri, 28 Jul 2023 14:36:52 +0200 Subject: [PATCH 7/7] chore: added note on the same device flow --- docs/en/relying-party-solution.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 0c37ba232..8698b7ec1 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -110,6 +110,9 @@ In the Same Device Flow the Relying Party uses a HTTP response redirect (status client_id=https%3A%2F%2Fverifier.example.org%2Fcb &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. + Where: .. list-table::