Document how redirectUrl can be used to do session binding if necessary

[dlongley]

In some scenarios, polling isn't used to obtain completed exchange information, but rather, the RP will not act on an exchange until it is redirected by the user to a particular URL. This URL is returned via redirectUrl in the completed exchange response to the wallet (which is responsible for enabling the user to then navigate in their browser to the URL). Only once the RP is redirected to this URL (note: the redirect URL is kept secret from the wallet until the exchange completes successfully) will the RP get the completed state of the exchange and act accordingly.

This pattern requires the user to navigate away from the page where the exchange started, but offers the benefit of enabling the RP to ensure that when the user visits the redirection page -- that it is the same user (the same "session"). This can be done by having the RP make the redirect URL a capability URL and storing an association between it and the user's current session. For example, the user's browser can store a session cookie (e.g., a cookie value with a session ID) and the RP's backend can store the redirect capability URL in that session information. An RP can check this value against the URL when the user returns to ensure that the user that completed the exchange is the same one that started the exchange, mitigating a variety of phishing threats.

This should also be documented as a useful pattern in the VC API spec.

[dlongley]

An additional pattern could be for implementations that serve the response to a redirect URL to show a code if a different device is detected (i.e., the user did a cross device flow). The web page can direct the user to enter the code on their own device at the page where the exchange began, also causing binding that way.

In other words there are two flows supported here. The first two steps are the same:

1. User uses their desktop to start an exchange.
2. The web server stores a cookie on the desktop browser to be read later if the user's desktop browser navigates to redirectUrl at the end of the exchange.

Then, the next few steps can vary, either:

3. User completes the exchange using their desktop browser.
4. User's desktop browser goes to redirectUrl and the web server detects the cookie and considers the exchange to have involved the same user.

OR:

3. User completes the exchange on their phone's browser.
4. User's phone browser goes to redirectUrl and the web server detects no cookie and instead renders a short code and instructs for the user to enter it into their original device's browser.
5. The user switches to their desktop, clicks a "I used another device to complete this flow" button which causes a form to be rendered where the user enters the code into the form to signal to the server that the exchange is complete and involved the same user.

[msporny]

instead renders a short code and instructs for the user to enter it into their original device's browser.

Wouldn't the desktop just poll in the background and detect when /something/ went to the redirectUrl and can thus conclude that the flow is complete?

[dlongley]

@msporny,

Wouldn't the desktop just poll in the background and detect when /something/ went to the redirectUrl and can thus conclude that the flow is complete?

First, note that a requirement here is that polling isn't being used to begin with in this scenario. But, more importantly, the purpose of this flow is to ensure that the user that completed the exchange is / was the same user. Polling and allowing the flow to complete if anyone (or "something" as you say) used the redirect URL without reestablishing some binding with the original channel / browser would not provide what's required: to establish the binding between the user that completed the exchange and the original channel in which it was initiated.

[msporny]

First, note that a requirement here is that polling isn't being used to begin with in this scenario. But, more importantly, the purpose of this flow is to ensure that the user that completed the exchange is / was the same user. Polling and allowing the flow to complete if anyone (or "something" as you say) used the redirect URL without reestablishing some binding with the original channel / browser would not provide what's required: to establish the binding between the user that completed the exchange and the original channel in which it was initiated.

Sure, but I guess my point is, there is no guarantee that the person entering the code is actually the one that completed the flow. An attacker working in conjunction w/ the real holder of the VC can always just pay someone for their code... this is the same issue as relay proxies, which I would imagine /every/ solution that attempts to do channel binding in this way has.

[dlongley]

Sure, but I guess my point is, there is no guarantee that the person entering the code is actually the one that completed the flow.

To clarify, the aim is not that it's the same person, but that that same user sanctioned the completion of the flow. They could have delegated to / involved another person, but only with their consent.

An attacker working in conjunction w/ the real holder of the VC can always just pay someone for their code... this is the same issue as relay proxies, which I would imagine /every/ solution that attempts to do channel binding in this way has.

Yes, this flow does not prevent collusion (nor does it aim to). It aims to stop an attacker that is working against the user, not an attacker that is working with them.

And, yes, I agree that no "channel binding" scheme will prevent collusion (and it doesn't aim to).