Can you expand on what "Client Provided Session" means?
In the browser session authentication use case, as well as a sqrl:// scheme link being launched the browser makes a parallel internal probe and then direct GET request to http://127.0.0.1 on port 25519 which is locked by the local client the payload of the original link base64URL is encoded in the url, which hands over control of what follows to the client application.
The client performs authentication as normal, but instead of the session being updated via a browser push a redirection response is returned to it via the client which leads to a single use very temporary and unguessable link that kicks off the authenticated session.
Because of browsers same origin policies and other security protections we believe it is not possible for an MITM attacker actively tunneling a valid SQRL login page to gain access to this information.
Clearly this does rely on the browser agent upholding strict security policies, but then if it did not you would have much bigger problems.
If it does require native browser support, I would worry about chicken and egg adoption issues.
Provided that is the attacker is not using same domain origin, scheme, port etc. Which if they were you would perhaps have greater problems.
That said, we will all be testing that feature most thoroughly.
I think the only way this could work is if you set the window.location to localhost:25519 when starting the SQRL authentication. That will result in harder UX problems to solve but it does seem feasible.
Regardless, having reviewed FIDO and the W3C Web Authentication API, it seems to me that SQRL doesn't have a chance of seeing any wide adoption once those two are available. They have the dual advantage of standardization and platform control that are nearly impossible to overcome by external offerings.