- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Jun 2022 23:35:56 +0000
- To: public-webauthn@w3.org
> While I generally agree that this results in a poor user experience, this is not new and existed prior to multi-device credentials. That isn't a valid excuse or reason that we can't fix this experience *now*. > The debate (or at least a significant part of it) is whether this is a power we want to give to RPs. I feel like this WG has consistently only acted in the interest of device manufacturers and browsers, and leaves RP's to deal with a hot mess, that we need to somehow implement inside of all the other regulations and requirements that RP's have, and that it's up to RP's to try to create a somehow good user experience inside of a very poor canvas. Which goes completely against the intent of trying to enable and create a seamless user experience, when instead we are creating a scenario for many tiny bad ones that will frustrate users. > All that said, though, an argument in favour of something like https://github.com/w3c/webauthn/pull/1744 is that a feature toggle could enable users to use an authenticator that would otherwise be rejected. There is already precedent to this, because google chrome would only show you a security key prompt even when touchid and other sources were available, and made the toggle to find other credentials basically invisible. It was only in self-interest when android caBLE was being released that they changed it to force that caBLE and android was always an option. For all the comments about trying to create a good user experience where users can use whatever device they want, this immediately collides with reality where chrome has disallowed that in the past. The irony is further not lost on me, that google itself doesn't accept anything thats not a u2f key at the moment it seems (I've tried to enroll touchid and it doesn't work, google backend rejects it without prompting as to why.). What is a problem here is that workplaces and enterprises exist and we have requirements and regulations that we need to up hold. A toggle that allows the user to "yolo let me just wreck my experience" would be fine provided that we can guide that initial UI/UX, but we are then back to the hostage situation of then getting chrome to implement it. > 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. Fully. Agreed. To further this, when we *know* the make and model of the keys we issue, why both prompting for caBLE when only a usb-yubikey would work. That's why we want to have these flows. If you want to read about this in excruciating detail, https://fy.blackhats.net.au/blog/html/2022/06/13/exploring_webauthn_use_cases.html -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1739#issuecomment-1160954876 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 23:35:58 UTC