- From: Mike Fisk via GitHub <sysbot+gh@w3.org>
- Date: Fri, 30 Jun 2023 19:45:21 +0000
- To: public-webauthn@w3.org
I can speak from and perspective of 3 RPs, both commercial (including banking) and government. This is an important issue for workforce (not consumer) authentication — the places where hardware tokens have had market penetration. 1. In this world, the RP has other roots of trust with the user and often wants to own the device enrollment/recovery flow. 2. The RP also often wants to limit access to corporate/compliant devices and does not want transparent moving on private keys from a corporate device to an unknown/personal device. 3. From a compliance and accreditation perspective, a device-bound key includes the device OS as part of the in-scope solution/system, but with ecosystem portability like Apple has, the compliance scope now includes the iCloud account recovery and new device enrollment process which is significant new complexity and with no change mangement to determine if new iCloud logic is understood by the RP or is considered acceptable to the RP. This is an untenable situation to some regulators. Being able to require a single-device key that cannot be extracted from the device is a basic requirement. It is highly disappointing that FIDO2 platform implementations have been regressing from hardware-protected keys to cloud. On laptops this will drive continued use of separate hardware keys but on mobile this practice really undermines the ability to use FIDO2 for high-security applications. Worse yet, on iOS 16, if the user disables cloud backup of their keychain, iOS actually refuses to enroll a new passkey at all. That’s just crazy to me. -- GitHub Notification of comment by mfisk Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1640#issuecomment-1615121937 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 30 June 2023 19:45:22 UTC