- From: Shane Weeden via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Jun 2022 22:44:54 +0000
- To: public-webauthn@w3.org
> The debate (or at least a significant part of it) is whether this is a power we want to give to RPs. Yes please. > 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). It can be argued this *is* putting users first, but delivering them the user experience required by the RP's policy. > 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. The consensus or lack thereof is from the platform vendors vs the enterprise RP camp. The settings that are already possible using attestation are again all POST-ceremony error handling, and not the orchestration of a ceremony that matches the RP's requirements. > I think the `devicePubKey` extension (#1663) is an appropriate compromise. I'm not convinced it is, because: - This is technically very difficult to adopt; - Requires attestation itself to be trusted (which nobody has committed to delivering) - Also requires for account sovereignty requirements an additional non-FIDO second factor or other identity proofing mechanism remain in place so that it conditional application of it can be applied on new device registration (ie. when a passkey is used from a new device for the first time). What the enterprise RP stakeholders are asking for is different. Give me a device bound credential assurance, and don't complete a registration ceremony unless that's what is going to happen. I'm not certain such an ask is entirely possible, since the device-boundedness cannot always be determined for "attached" authenticators, however that doesn't mean the RP should not be allowed to express their policy. -- GitHub Notification of comment by sbweeden Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1739#issuecomment-1160914904 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 22:44:56 UTC