- From: Emil Lundberg via GitHub <noreply@w3.org>
- Date: Mon, 20 Oct 2025 10:32:07 +0000
- To: public-webauthn@w3.org
I must say I'm against this for much the same reasons as #2252 and #1714: it should not be the RP's place to tell the user they're _not allowed_ to use a non-syncing authenticator if they so choose. If anything, I would say the motivation in the explainer: >Authenticators are and have been moving towards syncing, not the other way around. actually weakens this proposal, rather than strengthening it. If the market is consistently moving toward syncing as the path-of-least-resistance default, then why does the RP need to actively hinder users who _go out of their way_ to give themselves the problem that their passkeys won't be backed up? I do recognize the RP's desire to reduce the risk of users getting locked out and needing support and recovery help, though. On a recent WG call I suggested a (very half-baked) alternative to that end: instead of the API guaranteeing one backup-eligible credential, what if it would return a _set_ of credentials satisfying _at least one_ of: - The set contains at least two credentials (created on different authenticators by setting `excludeCredentials` under the hood), or - the set contains at least one backup-eligible credential. This would, in theory, address the "single point of failure" lock-out concern while not disadvantaging device-bound credentials too much. I vaguely remember some objections about implementation/UI complexity, but would you care to remind me (and for the record) what were the reasons something like that wouldn't be a good solution? -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2342#issuecomment-3421502459 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 20 October 2025 10:32:08 UTC