Considerations on using WebAuthn in cross-origin iframes and Storage Access API

[alanwaketan]

On WebAuthn Level 2, the spec utilizes Feature Policy to allow a first party main frame to opt in for WebAuthn in a third party iframe. This new capability allows for a more streamlined experience for SSO or payments.

However, it doesn't consider the Storage Access API, which has to be used if the third party iframe is blocked from accessing its cookies. The API requires user interaction and may display its own prompt to the user. I believe the envisioned use cases do need third party cookie access in order to fulfill their functionalities. Therefore, we will end up in a situation that users might be prompted twice, once from WebAuthn and once from Storage Access API. This user experience doesn't sound more streamlined than the one utilizing a redirection or a pop up instead of the iframe where users won't be prompted by the Storage Access API.

To achieve the envisioned functionality, some spec work is needed to bridge WebAuthn and the Storage Access API. Some related issues are: #1336, #1303, and #1293.

[nadalin]

@alanwaketan Clarification on use case needed

[agl]

I hope that iframes can operate without any local state. (I.e. no cookies nor local storage). The top-level frame should be able to get the necessary data and postMessage it in.

[alanwaketan]

If that's the case, then I think we are good with Storage Access API. Should we add some notes in the spec to warn developers?

[equalsJeffH]

in 2020-02-26 meeting we agreed that given the way things are moving that webapps using 3p iframes ought to assume that there's no state maintenance for them, they are going to start stateless, and the embedding frame needs to postMessage() state into the embedded iframe. exposition of implementer considerations ought to go into external webdev documentation such as MDN.

[rmondello]

Agreed. Not a spec issue, but something that’s worth messaging to developers.