Define what happens when the Document loses focus #316
Comments
|
You mean U2F client implementations in browsers I presume. Is this sort of impl considerations written down anywhere (eg mailing list archives, release notes, api documentation, etc) or is only ensconced in code? |
|
I don't see any use cases of any WebAuthn operation when the UA changed the focus, especially considering that the API is not under worker. Let's try to get this in spec soon so that we avoid attacks. |
|
https://w3c.github.io/web-nfc/#handling-window-visibility-and-focus has an attempt to handle focus changes for the NFC API. I think some of the details there have problems, but it points to useful hooks in HTML and Page Visibility. |
|
If we are going to specify behaviors for this case, we should do so for the Implementer's Draft, since they will affect interop. Or we can decide to leave this unspecified and explicitly document it as such. |
|
I have started on this, but I got a bit hung-up on cross-linking into visibility. Basically, I've barely started, but at least I have a branch... |
|
The WebNFC spec defines a member variable that is checked at explicit points during the algorithm run. I'm wondering if we could do something simpler, like: Handling Window Visibility and Focus ## {#visibility-and-focus}When the [=Window=] object associated with the [=Document=] using the Web Authentication API {{loses focus}}, then:
Note: This would have the effect of stopping the display of credential selections, or halting a blinking light.
|
|
@jcjones I think you also need a check that the document has focus before starting authenticator operations, and we should make sure that the "loses focus" event happens in a task rather than in parallel so that there aren't race conditions. Arguably, something should actually maintain the set of "running operations", so there's an explicit set of things to cancel, but I'm not sure that's essential. |
|
Are there examples of.. "..we should make sure that the "loses focus" event happens in a task rather than in parallel so that there aren't race conditions" ..in extant whatwg/w3c specs we can examine? |
|
Sorry, by "we" I mostly meant the HTML editors. WebAuthn just needs to use the right hook in HTML, which is now tracked in whatwg/html#2711. |
WebAuthn operations that are in-flight with authenticators must be cancelled when switching tabs. There's an Issue [1] opened with the WebAuthn spec for this already, but the language is _not_ in spec. Still, it's necessary for security, spec or not. This also matches how Chromium handles U2F operations during a tab switch. [1] w3c/webauthn#316 MozReview-Commit-ID: 6Qh9oC4pqys --HG-- extra : rebase_source : ad1665b8140f74b1291f17994285e6146c4ec468
WebAuthn operations that are in-flight with authenticators must be cancelled when switching tabs. There's an Issue [1] opened with the WebAuthn spec for this already, but the language is _not_ in spec. Still, it's necessary for security, spec or not. This also matches how Chromium handles U2F operations during a tab switch. [1] w3c/webauthn#316 MozReview-Commit-ID: 6Qh9oC4pqys
WebAuthn operations that are in-flight with authenticators must be cancelled when switching tabs. There's an Issue [1] opened with the WebAuthn spec for this already, but the language is _not_ in spec. Still, it's necessary for security, spec or not. This also matches how Chromium handles U2F operations during a tab switch. [1] w3c/webauthn#316 MozReview-Commit-ID: 6Qh9oC4pqys
|
We decided in WebAuthn WG F2F meeting that this issue can be closed. |
|
The issue is added in pull request #544 |
WebAuthn operations that are in-flight with authenticators must be cancelled when switching tabs. There's an Issue [1] opened with the WebAuthn spec for this already, but the language is _not_ in spec. Still, it's necessary for security, spec or not. This also matches how Chromium handles U2F operations during a tab switch. [1] w3c/webauthn#316 MozReview-Commit-ID: 6Qh9oC4pqys UltraBlame original commit: f7a53ff2f8cb312eb6a65b127207e04d2bd1c79c
WebAuthn operations that are in-flight with authenticators must be cancelled when switching tabs. There's an Issue [1] opened with the WebAuthn spec for this already, but the language is _not_ in spec. Still, it's necessary for security, spec or not. This also matches how Chromium handles U2F operations during a tab switch. [1] w3c/webauthn#316 MozReview-Commit-ID: 6Qh9oC4pqys UltraBlame original commit: f7a53ff2f8cb312eb6a65b127207e04d2bd1c79c
WebAuthn operations that are in-flight with authenticators must be cancelled when switching tabs. There's an Issue [1] opened with the WebAuthn spec for this already, but the language is _not_ in spec. Still, it's necessary for security, spec or not. This also matches how Chromium handles U2F operations during a tab switch. [1] w3c/webauthn#316 MozReview-Commit-ID: 6Qh9oC4pqys UltraBlame original commit: f7a53ff2f8cb312eb6a65b127207e04d2bd1c79c
(Related to #292)
If an operation such as makeCredential or getAssertion is in progress, and the UA changes focus (e.g., the user switches tabs), what should happen?
I believe it is the case that at least some U2F implementations cancel all operations in-flight and return errors, to avoid potential phishing or denial of service attacks. If that's correct, we should define that behavior for WebAuthn as well.
The text was updated successfully, but these errors were encountered: