feat: [RP] same device flow #77
Conversation
docs/en/relying-party-solution.rst
Outdated
| 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 | ||
|
|
There was a problem hiding this comment.
Shall we add that the user will first have to select their wallet provider?
There was a problem hiding this comment.
Why?
in the presentation phase the user interact directly to the RP with their wallet instance.
What would you like to say?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Maybe we should better clarify the scenario. I see at least the following scenarios:
- 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...
- 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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
…e for the VP parameters
| - 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. |
There was a problem hiding this comment.
This is valid if there is only one verifier. If there is more than one then RP will have to make the user choose his Wallet Provider to provide the correct redirect url.
This PR closes #74