- From: Matthew Miller via GitHub <noreply@w3.org>
- Date: Fri, 26 Jun 2026 18:16:30 +0000
- To: public-webauthn@w3.org
@kenrb and I had a good chat today about ⬆️ this. I've come around to the idea that from an API perspective these WebAuthn execution modes like ambient UI or immediate mediation, in which we're not guaranteeing that the user would be shown anything by the browser, could benefit from **requiring** that `mediation: conditional` be set: 1. `mediation: conditional` + `uiMode: passive` = ambient; **browser decides** whether to show any UI 2. `mediation: conditional` + `uiMode: immediate` = immediate mediation; **browser decides** whether to show any UI (depending on the shape that #2291 ultimately takes) 3. No `mediation`: **browser always shows** the WebAuthn modal Then developers can internalize, "in the absence of `mediation: conditional` the user will always be shown UI, even if it's only hybrid," and "when `mediation: conditional` is set, the user may not be shown any UI if the browser decides not to." I was getting hung up earlier on the fact that `mediation: conditional` is the same value for either `uiMode`, therefore it felt superfluous. But now having talked it out I think that **requiring** `mediation: conditional` be present can actually make these WebAuthn calls more "glanceable" to devs as to what experience the user may (or may not) see when the WebAuthn API call is ultimately made. -- GitHub Notification of comment by MasterKale Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2144#issuecomment-4812263816 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 26 June 2026 18:16:31 UTC