Some clarifying questions:

1. You referring to the UI rendered by the platforms (Browser/OS) as opposed to the UI rendered by the relying party, correct?
2. What do you mean with "user gesture restriction" (restricting the number of dialogs, or restricting the user gesture to a specific modality like Fingerprint, or something different)?

Today, Firefox on Windows 10 will only trigger the Windows dialog for prompting the user gesture and selecting the modality. Chrome on Windows will
a) ask the user to confirm credential creation
b) trigger the Windows dialog for prompting the user gesture and selecting the modality
c) ask the user to accept "direct attestation" conveyance if that was select by the relying party.

@rlin1 Right, it refers to the user agent's UI not the RP's. What we want ultimately is to throw exceptions for WebAuthn calls that don't have user gestures, and therefore don't even bother to show any UI.

there are cases that will break for our deployment if this was instantiated. on todays 11-Sep call several folks mentioned this would break their deployments or ones they are aware of.

We cannot break deployments out there with this breaking change. Multiple RPs (including ours) deployment will break with this change.

@equalsJeffH @akshayku We understand that it is a breaking change. However, we believe this will benefit the whole community in long term assuming phones become major clients and authenticators in the future.

As a client, phones usually have much smaller screen asset, in which the user agent UI could take up a very large portion of the screen, even in some implementations the whole screen. This makes an unsolicited dialog even more disruptive.

As an authenticator, assuming phones can be used as a wireless authenticator, unsolicited notifications received from other hosts are effectively spam.

We think neither of the above case is acceptable user experience, and therefore strongly demand some user gesture requirement to guard the UI if not the whole API.

In fact, it is not just about UI. If user agents starts NFC scanning and BLE advertisement at the meantime when the API is called, it leads to a bigger problem that might leak user information. We know some implementations have guarded NFC scanning and BLE advertisement in their own UI by explicitly asking users what transport they want. This cumbersome design can be avoided if user gesture is required at the very beginning of the API calls.

On the WebKit side, we may consider guarding our API with user gestures but whitelist RPs that would be broken.

@alanwaketan what kind of gestures are you referring? Clicking a button (or prompt) provided by user agent? Or, just swiping some UI component?

From the 20-Sep-2019 TPAC WebAuthn F2F meeting (minutes):

Given the discussions on this, and that existing flows it would compromise, we noted we can continue to think on this for the time being, moved it to L2-WD-03 milestone.

Note: Ricky said in closing: for clarification. we are hestitant to let third party i-frames to [ call nav.creds.create() ] without a user gesture.

We agreed to hold this issue and revisit it again to give time for RPs to adopt as mentioned in the 20-Sep-2019 TPAC WebAuthn F2F meeting.

Here we would like to recall the intent. The intent is really for preventing showing system level UI without explicit user consents. User agents might be able to fold the UI into a Javascript dialog like UI for roaming authenticators, but it is hard to imagine how that would work for platform authenticators.

Relevant topic re: Push and user interaction - https://blog.mozilla.org/futurereleases/2019/11/04/restricting-notification-permission-prompts-in-firefox/

on 2019-Nov-06:
@jcjones noted that the issues with web push noted in issue #1336 also apply here.

on 2020-01-22 call: chrome folks @agl indicated that changing this esp for top-level contexts would be very problematic for us, more sanguine re cross-origin iframes. @jcjones thinks this applies for cross-origin iframes. presently top-level context must obtain user interaction to do full-screen. @jcjones thinks this is still valid issue -- is 2 sep issues:

(a) (needing?) cross-origin iframes (to be?) interacted with before webauthn ceremony completes, and

(b) requiring user interaction for all webauthn ceremonies for any context.

a thought/question is whether user interaction with top-level context can be used to allow webauthn in embedded cross-origin contexts.

@agl notes that (b) is a big deal and browsers would need to coordinate. @jcjones notes that we need to review what the definitions for "interact" are? (moving one's mouse? blinking/winking at the camera?) we ought to look at what the fullscreen API has done....? (but might be disappointed there...)

on 2020-01-29 call: understanding is that @jcjones was going to go do some further research on this eg fullscreen api's approach.

Absent a threat that indicates this need, I think this is reasonable to close for now, for re-opening in some future time when we have better understanding of adversarial use, if any.

Absent any further comment to @jcjones #1293 (comment), we're closing this for now. It can be re-opened if there's objections or we better understand things.

It seems that WebKit/Safari has now implemented this, see https://bugs.webkit.org/show_bug.cgi?id=213595.

This broke an auth flow in Keycloak (an IdP) that was using onLoad to fire the WebAuthN for me personally. Figured I'd leave this comment in case anyone else comes looking as to why Safari (Mac OS Big Sur, Safari 14.1) is failing to use WebAuthN with an error similar to:

User gesture is not detected. To use the WebAuthn API, call 'navigator.credentials.create' within user activated events.

With exceptions for the big players, introduced after some (seemingly intense, internal) discussion in https://bugs.webkit.org/show_bug.cgi?id=220897

I'm kinda surprised GitHub didn't make the list 😂

Just to note: although @alanwaketan's original framing says "Requiring user gesture..." --- which some may confuse with the WebAuthn API's notion of requiring (or not) a "gesture" for user verification --- it seems this is actually in regards to the (sort of new) HTML notion of "Tracking user activation", and there being Web APIs that are "gated by user activation". ( see also User Activation v2 as well as its Chromestatus feature page )

The latter is described as: "user agents allow [the RP to call certain] APIs only when the user is actively interacting with the web page or has interacted with the page at least once". Thus it seems it is a notion distinct from WebAuthn's "gesture" for user verification.

Nominal assessment (disclaimer: AFAICT)

1. A given Web API is obliged to assess its characteristics and decide whether it ought to be "gated by user interaction", and if so, in which fashion. This may require updating the Web API's algorithm's specifications. E.g., see WebPayment's show() method, steps 2 & 3. [ It also appears by inspection that the latter method would be classified as a "transient activation-consuming API" (if the spec authors were to document their user activation classification), fwiw ] [1]

2. The WebAuthn spec is presently unaware of "user activation", and so does not explicitly accommodate it.

3.1. It appears that updates to WebKit, as noted immediately above in #1293 (comment) and #1293 (comment), have imposed a notion of "user activation" upon use of the WebAuthn API in WebKit-based UAs, while other UAs have not done so (?).

3.2. It is not clear (to me) from https://trac.webkit.org/changeset/272345/webkit in which fashion, as classified in "APIs gated by user activation", WebKit has imposed its user activation requirement upon the WebAuthn API.

Conclusions:

C1. We ought to determine whether we need to update the WebAuthn API spec to explicitly handle "user activation" in some fashion that we agree on, such that it's implemented uniformly in UAs.

C2. This issue ought to actually be entitled "Requiring user activation to call WebAuthn API"

C3. Given this assessment as well as #1293 (comment) and #1293 (comment), I'm re-opening this issue.

cc: @akshayku @agl

[1] Some other specs, in addition to WebPayment, explicitly handling "user activation", are (not an exhaustive list):

• WebXR: https://www.w3.org/TR/webxr/#applicationflow
• Audio-Output: https://www.w3.org/TR/audio-output/#dom-mediadevices-selectaudiooutput

In my tests with Safari 14.1 and 14.2 on OSX the requirement for user-activation now also applies to external security keys.

I don't see an exception being made for google.com. I will try and check some of the others, but the shouldBypassUserGestureRequirementForWebAuthn list seems to not be working at least for me in Chile.

It seems to work for facebook.com, twitter.com, and dropbox.com.

microsoft.com is not giving me the option to signing with a security key on Safari so I can't tell if it is broken.

I have had other SaaS start to complain about this Ping etc. Who should people go to to get on this list?

I have had other SaaS start to complain about this Ping etc.

Correct. We had no expectation that this WebKit-only behavior would expand from platform authenticators to all authenticators.

As an authentication product, changing how the authentication process is integrated between domains is a fundamental change to product integration with our customers.

Like other companies whitelisted, authentication is done by a separate logical application. Also like many of the other companies whitelisted, we also have that authentication system sometimes under a different eTLD+1 (e.g. federated-style login). This means that the user selects that they want to authenticate on one domain, then is redirected to perform the actual authentication process. As a result, this use of the first user interaction for authentication would require moving the authentication process to another origin and break existing credential registrations.

Worst case, WebKit users of our products continue to get a degraded user experience (extra click required to confirm again they really really wanted to do webauthn) and some percentage of our customers decide to not support or even disable WebAuthn support with any WebKit-identified user agents as a result of poor user experience.

Hello everyone, we may be able to finally close this out. It's been observed recently that Safari 16.0 has completely relaxed the user gesture requirement, allowing for WebAuthn to be invoked immediately on page load without any kind of user interaction.

I recorded a screenshot of a simple page that immediately invokes navigator.credentials.get() on page load, with a button to also invoke .get() with a user gesture. In both scenarios there are no issues triggering WebAuthn:

I tested some more with this basic page in Browserstack and saw the same behavior in Safari 15.6 (and maybe earlier, but this was the only 15.x version I could test). I had to go back to Safari 14.1 to get back to a version that refused to invoke WebAuthn without a user gesture.

Chrome Stable 106 also acted exactly the same as Safari 16.0 today. @nsatragno confirmed that Chrome currently has no such user gesture requirement and may never have; I thought Chrome used to at least require some kind of user interaction even if it didn't directly invoke WebAuthn (client-side routing redirect, make an async network request, etc...) but currently it doesn't.

Based on this I think it's safe to start telling people that they can re-evaluate logic that might have tried to account for this, and that WebAuthn should be safe to invoke without additional considerations than needing to provide a secure context.

Would be nice if someone from Apple could confirm this is no longer a requirement for use of the platform authenticator?

Would be nice if someone from Apple could confirm this is no longer a requirement for use of the platform authenticator?

Ricky Mondello at Apple had this to say via Twitter about Safari's updated behavior:

Safari 16 changes the user gesture policy. Each tab gets a “freebie” attempt at a .get without a user gesture. After that, the user gesture requirement comes back. So I’d keep some of your handling around — be able to handle rejection and get a user gesture.

And there's an earlier take of the video I posted in which I successfully use the platform authenticator from one of these prompts:

I hope that helps. I'm cautiously optimistic that we can spend less time trying to intuit what constitutes a "sufficient" user gesture now when invoking WebAuthn in Safari when we want to use the platform authenticator.

Safari 16 changes the user gesture policy. Each tab gets a “freebie” attempt at a .get without a user gesture. After that, the user gesture requirement comes back. So I’d keep some of your handling around — be able to handle rejection and get a user gesture.

I think this specific flow Apple has decided to use is probably representative of the vast majority of implementations prior to them considering Apple's unique way of handling Webauthn, or implementations that never considered it. i.e. either all attempts are triggered by a gesture (typically a click) or if there are automatic attempts then they're only the first attempt.

Chrome Stable 106 also acted exactly the same as Safari 16.0 today. @nsatragno confirmed that Chrome currently has no such user gesture requirement and may never have; I thought Chrome used to at least require some kind of user interaction even if it didn't directly invoke WebAuthn (client-side routing redirect, make an async network request, etc...) but currently it doesn't.

I think it's possible this only happened on Apple devices, specifically iOS devices. I'm not certain of this, however the underlying reason I believe this is that all browsers at least on iOS are effectively rebranded Safari browsers.