Add Immediate Mediation

[kenrb]

This specifies the behaviour of the mediation: 'immediate'.

Issue: #2228
Explainer: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation

Parallel PR adding the enum to Credential Management: w3c/webappsec-credential-management#272

---

Preview | Diff

[kopy]

While I understand the privacy considerations underlying AllowList limitations, requiring explicit user activation significantly restricts practical usability at scale for this scenario:

• Direct use on standard login pages (typical scenario for most websites) is the main issue addressed here. If an email input field is already visible, requiring further user activation for immediate mediation becomes unintuitive, as the user may have already started typing their email. A lot of websites have a profile or menu and not a "sign-in button" on the upper right or use "layers"

Removing the strict requirement for explicit user activation, aligning with existing first-party WebAuthn implementations, would substantially enhance usability. Immediate mediation could then seamlessly activate upon page rendering, offering a smoother authentication experience before users interact with input fields. Notably, every native implementation that supports preferImmediatelyAvailable—such as on Android and iOS—do not require a user activation.

Currently, adopting this approach broadly would necessitate extensive UI and workflow adjustments. Furthermore, login pages often redirect users to relying-party single sign-on systems, making UI changes challenging and potentially disrupting existing authentication workflows.

[Firstyear]

Having webauthn prompts randomly trigger on a page load with no explanation or context for users, sounds like the exact opposite of good UX to me - it sounds a lot more like a path to confusion and frustration.

[kopy]

Having webauthn prompts randomly trigger on a page load with no explanation or context for users, sounds like the exact opposite of good UX to me - it sounds a lot more like a path to confusion and frustration.

This could still happen after the user navigates to the login page or exactly where it does now. It’s not random we leave it up to RPs - we had this exact same dicussion with WebAuthn user gestures for Safari and they were lifted. As someone responsible for large consumer RP implementations, I have problems seeing clearly how this approach helps for most pages.

[kenrb]

This could still happen after the user navigates to the login page or exactly where it does now. It’s not random we leave it up to RPs - we had this exact same dicussion with WebAuthn user gestures for Safari and they were lifted. As someone responsible for large consumer RP implementations, I have problems seeing clearly how this approach helps for most pages.

The main advantage of not having a user gesture requirement for existing modal WebAuthn calls is that they can be used for re-auth, a use case for which immediate mediation isn't useful.

Immediate is aimed at scenarios in which a user has done something to indicate a sign-in is appropriate at that time. This isn't precisely replicating preferImmediatelyAvailableCredentials on mobile because the web has different privacy properties.

There is a separate proposal for a mode called Ambient, in which more subtle (non-modal) UI is displayed to offer the user an opportunity to sign-in, and would not require user activation. https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Ambient-Signin-UI

That proposal is still active.

[kopy]

This could still happen after the user navigates to the login page or exactly where it does now. It’s not random we leave it up to RPs - we had this exact same dicussion with WebAuthn user gestures for Safari and they were lifted. As someone responsible for large consumer RP implementations, I have problems seeing clearly how this approach helps for most pages.

The main advantage of not having a user gesture requirement for existing modal WebAuthn calls is that they can be used for re-auth, a use case for which immediate mediation isn't useful.

I see your point, but my comment referred to the fact that continuously triggering WebAuthn requests hasn’t yet emerged as a significant abuse issue. WebKit also moved away from enforcing user gestures for WebAuthn, recognizing that plenty of alternative approaches are available to effectively rate-limit such behavior. For example, I can see why this is useful in cross-origin iframes.

Immediate is aimed at scenarios in which a user has done something to indicate a sign-in is appropriate at that time. This isn't precisely replicating preferImmediatelyAvailableCredentials on mobile because the web has different privacy properties.

There is a separate proposal for a mode called Ambient, in which more subtle (non-modal) UI is displayed to offer the user an opportunity to sign-in, and would not require user activation. https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Ambient-Signin-UI

That proposal is still active.

I am aware; thank you, @kenrb. I greatly appreciate Chrome’s efforts to improve the passkey experience. Immediate mediation is helpful, but only precisely for the UI case you mentioned - it’s just challenging for some RP implementations. I was simply suggesting making it more broadly applicable; perhaps the ambient proposal would be better suited.

[zacknewman]

Do we want an error to occur if an RP uses immediate mediation during credential registration, or is it sufficient to effectively treat it as an unknown enum value which in turn is treated as required?