- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Jun 2022 16:40:16 +0000
- To: public-webauthn@w3.org
We understand that RPs want this and how it would help prevent frustrating user interactions. The debate (or at least a significant part of it) is whether this is a power we want to give to RPs. The TAG recommends that [user needs come before the needs of web page authors](https://www.w3.org/TR/design-principles/#priority-of-constituencies). We don't want to end up with users needing to [carry several different authenticators because RPs can't agree which are acceptable](https://github.com/w3c/webauthn/issues/1688#issuecomment-1011516074). Therefore, so far there has not been consensus in favour of supporting more powerful authenticator discrimination. Some is already possible using attestation, of course, but the additional work required from RPs to use it (as opposed to simply setting a parameter) has been deemed enough deterrent against abuse. All that said, though, an argument in favour of something like #1744 is that a feature toggle could enable users to use an authenticator that would otherwise be rejected. For example if an authenticator uses cloud backup by default and would be rejected by an RP, disabling cloud backup for a particular credential might enable the user to use that authenticator for that RP. But on the other hand that makes it harder for the user to keep track of which credentials are backed up and not, which again is an argument against adding the parameter. I think the `devicePubKey` extension (#1663) is an appropriate compromise. It's an up-front signal that the RP wants something hardware bound, but doesn't impose any restrictions on the primary credential. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1739#issuecomment-1160655777 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 20 June 2022 16:40:17 UTC