Closed PieterKas closed 10 months ago
Interesting, in that "native controls" are limited within a browser. My big concern is how to have high trust it's a 1st party app. Communications could be protected with DPoP to some extent. Hmm...
I think the biggest issue for me with browsers is that we don't have any equivalent to an "OS App attestation". If the browser was willing to assert that the JS app was loaded from a particular domain and provides some sort of attestation as to the code it received (hash of loaded JS)... then maybe. There just are the same controls within the browser environment that there are for mobile applications.
Hi, OSW participant here :) Our main use case is reauthenticating the user of the SPA (step-up, transaction confirmation etc.) without leaving the context of the application, providing native experience at the same time. When using redirect-based flow for the same, the live data stream from the application will be interrupted. This includes (but is not limited to):
Iframes and popups could do the trick, but there are (at least) two problems here:
We can expand the new SPA security considerations section to include: https://aaronpk.github.io/oauth-first-party-apps/draft-parecki-oauth-first-party-apps.html#name-single-page-applications
A participant at OSW suggested they would consider using the native apps spec in the browser. That is contrary to our recommendations in the spec, but opening an issue here to keep track of it until we understand more about that use case.