Refinement of the presentation phase flow

[giadas]

The current version of the MSC seems missing some details and a clear distinction between cross and same device. To better clarify this, we suggest the following MSC (link) where we:

1. Specify that the User Agent can be on the same or different device of the Wallet Instance.
2. Remove the "user authentication" label as the presentation phase is more general.
3. Add the use of a cookie (transaction-id) to interact with the Relying Party. We remove the current Step 23 on updating the cookie. Is this ok or do we need this step? Can you clarify the meaning?
4. As the Relying Party cannot know if the User is using a User Agent on the same device where the Wallet Instance is installed. The Relying Party must provide both options to the User (Step 5): scan QR with the Wallet Instance (cross device) or automatically open the Wallet Instance (same device), based on this choice the flow enters in a different alternative (ALT) flow. This is a proposal, if you don't like it we need to think of an alternative that allows the Relying Party to know in which flow (cross or same device) the User is considering the UX requirements.
5. In the cross device flow, at Step 7, we specify that the User Agent will ask for the status of the transaction until a successful response is obtained (this can be mapped with current Steps 26-27, we moved them before).
6. Remove from the MSC the checks (e.g., trust, signature), we will add the details in the step-by-step description.

Open point: in the same device flow, in Step 21 the Wallet Instance must open the same User Agent where the flow started. This requirement is given by the cookie usage. Can the Wallet Instance retrieve the Browser information from Steps 10-11?

In addition, it should be clarified that this flow assumes a User visiting a Relying Party website from a browser (as a User Agent). It should be checked later whether the flow requires changes in case the Relying Party is a native app or the User starts the flow from the Wallet Instance.

As soon as we agree on the flow we can prepare a Pull Request with the new MSC and the updated step-by-step description.

CC @fmarino-ipzs

[peppelinux]

I agree Giada, here my notes

step 4 "create cookie", we assume that the cookie was already created to the anonymous session. Anyway a specialized cookie can be issued for this, then ok.

step 5 -> QR Code is misleading since the same-device only requires a 302 Found with e custom url-scheme/universal-link. QR Code is then required only for the cross device.

Specify that the User Agent can be on the same or different device of the Wallet Instance.

OK

Remove the "user authentication" label as the presentation phase is more general.

I agree

Add the use of a cookie (transaction-id) to interact with the Relying Party. We remove the current Step 23 on updating the cookie. Is this ok or do we need this step? Can you clarify the meaning?

transaction-id is misleading since in openid4vp draft it's going to be used for different scopes than the cookie. I agree that "update cookie" is misleading since the cookie may remain always the same while the binded session would updated in the RP backend.

As the Relying Party cannot know if the User is using a User Agent on the same device where the Wallet Instance is installed.

302 Found with a custom url-scheme or universal link would be handled to ask the user which application to use. If the web browser is not the same or with different storage (sandbox) the cookie would not be found and the endpoints would reject the request. This is how it is currently.

In the cross device flow, at Step 7, we specify that the User Agent will ask for the status of the transaction until a successful response is obtained (this can be mapped with current Steps 26-27, we moved them before).

I assume your step 18, it is not clear in your proposal but it's just an editorial, I believe that a developer may find more easy a solution like the one below where the JS is explicited in the text

Remove from the MSC the checks (e.g., trust, signature), we will add the details in the step-by-step description.

Not in favour of this since the Trust evaluation is a basic security component that needs to stay on top to give the correct guidance to the implementers

Open point: in the same device flow, in Step 21 the Wallet Instance must open the same User Agent where the flow started. This requirement is given by the cookie usage. Can the Wallet Instance retrieve the Browser information from Steps 10-11?

technically yes but at the expense of security, because the cookie produces an important binding and unlike any nonce or token it cannot be stolen from the browser via JS, given that it is secured and httponly. This is a security requirement that we meet in harmony with contemporary browser security features.

In addition, it should be clarified that this flow assumes a User visiting a Relying Party website from a browser (as a User Agent). It should be checked later whether the flow requires changes in case the Relying Party is a native app or the User starts the flow from the Wallet Instance.

I assume that a remote RP is a web service, even application/html or RESTful alway a web browser is then involved. In the introduction of the section we specify that the RP is remote and not a native app. Native apps are not considered within the flow.

I look forward for alingments between us for deciding the task to achieve in the next milestones, thank you @giadas !

[peppelinux]

@giadas @asharif1990 may we consider also https://github.com/italia/eudi-wallet-it-docs/issues/117 within an update of the RP flow?

[giadas]

step 5 -> QR Code is misleading since the same-device only requires a 302 Found with e custom url-scheme/universal-link. QR Code is then required only for the cross device.

How does the Relying Party establish whether the user is in the same or cross-device scenario? Here, we suggest to show (Step 5) a common page where the User can decide how to proceed, either by scanning the QR code (in case of cross-device) or by clicking on the app icon (same-device)

transaction-id is misleading since in openid4vp draft it's going to be used for different scopes than the cookie. I agree that "update cookie" is misleading since the cookie may remain always the same while the binded session would updated in the RP backend.

Ok, I will change the name of the cookie

302 Found with a custom url-scheme or universal link would be handled to ask the user which application to use. If the web browser is not the same or with different storage (sandbox) the cookie would not be found and the endpoints would reject the request. This is how it is currently.

I don't understand how you decide whether to send a 302 Found or show a QR code. Can you explain this point to me? (see first point for our suggestion)

I assume your step 18, it is not clear in your proposal but it's just an editorial, I believe that a developer may find more easy a solution like the one below where the JS is explicited in the text

Why step 18? Our Step 7 corresponds to your Step 26, while Step 19 corresponds to your Step 27. However, in my opinion, it should be clarified that the Relying Party frontend starts requesting the response code after the scan of the QR code. This is why we move your Step 26 before.

Remove from the MSC the checks (e.g., trust, signature), we will add the details in the step-by-step description.

Not in favour of this since the Trust evaluation is a basic security component that needs to stay on top to give the correct guidance to the implementers

Let's agree together on the level of detail we want in an MSC.

Open point: in the same device flow, in Step 21 the Wallet Instance must open the same User Agent where the flow started. This requirement is given by the cookie usage. Can the Wallet Instance retrieve the Browser information from Steps 10-11?

technically yes but at the expense of security, because the cookie produces an important binding and unlike any nonce or token it cannot be stolen from the browser via JS, given that it is secured and httponly. This is a security requirement that we meet in harmony with contemporary browser security features.

I'm not sure I understand your answer. The cookie must stay in the browser, the point is that the Wallet Instance must open the same browser that was previously used. Is there any way for the Wallet Instance to know the calling Browser?

[giadas]

@giadas @asharif1990 may we consider also #117 within an update of the RP flow?

Regarding issue #117, we are working on it. We have extracted all the mitigations from the spec and are evaluating them. Probably next week we can share our set of suggested mitigations and discuss them together. As soon as the list of mitigation is agreed, we can update the step description and eventually the MSC. @marcopernpruner

[peppelinux]

@giadas

How does the Relying Party establish whether the user is in the same or cross-device scenario?

I have implemented an automatic inspection of the user-agent, there are consolidated ways to know if the device is mobile or not. https://github.com/italia/eudi-wallet-it-python/blob/dev/pyeudiw/satosa/backend.py#L230

I don't understand how you decide whether to send a 302 Found or show a QR code. Can you explain this point to me? (see first point for our suggestion)

In the previous link you can see how the inspection returns true or false if the device is mobile or not. Then is same device the 302 found is provided, while if not the qrcode is rendered to the user display

Why step 18? Our Step 7 corresponds to your Step 26, while Step 19 corresponds to your Step 27.

let's do a meeting for any further clarification on this

The cookie must stay in the browser, the point is that the Wallet Instance must open the same browser that was previously used. Is there any way for the Wallet Instance to know the calling Browser?

The browser must be the same, if not the flow, if securely implemented by the RP, should fail. In the satosa backend, in eudi-wallet-it-python, it fails.

We assume that the user has a single user agent if it is a lowtech or multiple user-agent if he/she is aware of which one to use

[fmarino-ipzs]

I move this issue to the milestone 0.7

[giadas]

As this issue is related to old content, I will close it. If necessary I will open new issues.