Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat: [RP] same device flow #77

Merged
merged 9 commits into from
Jul 28, 2023
Merged

feat: [RP] same device flow #77

Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
41929de
feat: [RP] same device flow
peppelinux Jul 24, 2023
6cd8731
Update gh-pages.yml
fmarino-ipzs Jul 24, 2023
eff780e
feat: [RP] same device flow improved
peppelinux Jul 24, 2023
825007c
Merge branch 'samedev' of https://github.com/italia/eidas-it-wallet-d…
peppelinux Jul 24, 2023
86926f1
Apply suggestions from code review
peppelinux Jul 26, 2023
05b550a
fix: SVG link, missing nonce in the presentation response, added tabl…
peppelinux Jul 28, 2023
ffedc19
Merge branch 'samedev' of https://github.com/italia/eidas-it-wallet-d…
peppelinux Jul 28, 2023
80881b7
fix: nonce goes just in the vp token and not in the authorization res…
peppelinux Jul 28, 2023
50721aa
chore: added note on the same device flow
peppelinux Jul 28, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 20 additions & 11 deletions docs/en/relying-party-solution.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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.

Expand All @@ -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

peppelinux marked this conversation as resolved.
Show resolved Hide resolved

Where:

Expand Down Expand Up @@ -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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we add that the user will first have to select their wallet provider?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

in the presentation phase the user interact directly to the RP with their wallet instance.

What would you like to say?

Copy link
Collaborator

@grausof grausof Jul 24, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the user has multiple wallet providers (multiple verifier apps) how do they decide which one to use?
The universal link is unique for each verifier app

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should better clarify the scenario. I see at least the following scenarios:

  1. The User starts a browser (external to the Walle Instance) in the device, wants to get access to a RP and the RP trigger the Wallet Instance for the User authentication...
  2. The User interacts directly with the Wallet Instance that provide a list of RP services to the User. The User select the service to which requesting the access and the Wallet Instance starts an embedded browser for the interaction with the RP.

In the case 1 we need the User select the Wallet Provider directly into the RP. In the second case, the wallet instance could handle the redirect as the User is already in the Wallet Instance.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, we really have to take out the possibility that the user should select the wallet provider in a RP discovery page.

The RP provides the QRCode, the User open their Wallet Instance and starts the flow.
At the end of the road we must adopt all the compromises to have the EUDI interop, then every member state will support the same things (even with custom extension but the same for interop needs)

for the PoC the user knows that a specific app is needed to start the flow

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, we should (or MUST??) avoid burdening the user with this. At the same time we should understand how to handle the Wallet Instance invocation in an external initiated scenario. I think this is the point. We could reach a compromise for the PoC but I think we should have a clear proposal on this topic regarding the EUDI interoperability.


Request Object Details
----------------------
Expand Down
Loading