- From: Arnar Birgisson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Dec 2023 18:04:26 +0000
- To: public-webauthn@w3.org
> Having allowCredentials: [] maybe just is not as useful as we originally thought. The RP cannot populate the allow list unless it knows who the user is, so they'd always have to ask for a username. Granted that could be autofilled, but it'd always be two confirmations for the user, as we could not automatically submit usernames to websites wihtout user approval. We are definitely finding that improved convenience is a much more appealing reason to use passkeys, for both RPs and users. The conclusion of that is that we really want to support a single-confirmation "type nothing" flow (aka usernameless). Our goal is improved security, but convenience is the carrot. > It sounds like the most elegant solution to me. Let the RP set allowCredentials and then the client only displays the intersection of allowCredentials and the credentials that are actually stored in the browser. It's not the greatest reason, but there are established use cases for FIDO/WebAuthn in reauth, where an RP explicitly does not want an account selector - only a UV step. That simplicity allows broader deployment of reauth, which is impactful for both friendly fraud and cookie theft. The fact that a populated allowList is the only way for an RP to signal this is maybe sub-par, but we can consider that legacy at this point I think. > use a well-known endpoint to check if the credential still exists or can be deleted. I think at least I believe this is more complex in the end. Besides defining a protocol between authnrs/providers and RPs (which is doable), there are non-trivial privacy and transparency implications of how providers should use this when the user is not involved. There are certainly privacy and DOS concerns with the report API, but here the user agent has full power to mitigate those. > [one passkey per person and] RPs can still allow a single passkey with multiple accounts by presenting an account selector after login. That is a fairly deep change to ask of RPs, as it can go as deep as modifying their data model for accounts. I also don't think the goal is to make passkeys represent a person, as that brings a whole host of complex and non-technical issues over treating passkeys as account credentials only. -- GitHub Notification of comment by arnar Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1967#issuecomment-1843406026 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 December 2023 18:04:28 UTC