- From: David Waite via GitHub <sysbot+gh@w3.org>
- Date: Sun, 23 Jan 2022 02:45:14 +0000
- To: public-webauthn@w3.org
I would argue it is a lot of work for likely zero reward. Authenticators today are defined by their behavior at their boundaries, not by the shape of their box. That means someone who disagrees with such a mandate will just stick to level 1 or 2, or implement level 3 without implementing that one piece. The only way you can actually tell from a relying party if an authenticator implemented level 3 correctly is via attestations. Attempting to mandate such implementation requirements also opens the group up to a lot of new work defining the shapes of those boxes based on suspected relying party policy logic. Today, `devicePublicKey` and that it is dealing with `devices` and `hardware` are easier definitions to set, because they are both opt-in and settling on whether an authenticator is implementing the extension correctly is a matter of conformance. As an example of the sort of challenges that pulling implementation details into working group responsibility causes, note that the current proposal for the extension has a `scope` value because vendors wishing to support this couldn't agree on whether it was bound to a hardware installation or to individual applications living on that hardware. I continue to argue that `scope` so far has no purpose from a risk system value, because such information should be gathered via attestation (also, I can't imagine what use knowing something is application-bound is when you can't detect you are on the same platform or not) The reality is that 'hardware' is made up of many components, and whether the private material of a public key credential can be extracted with a firmware update, a soldering iron or an electron microscope is not worthwhile without certification and attestations of conformance, which are not in this group's scope except for the mechanism we already have for securely conveying them - attestations. That logic gets even more complex once you look at the device-bound public key as part of a risk engine. Different relying parties actually care about different things, as we've seen with other protocol additions like enterprise attestations. A risk analysis product could be argued to likely want to take into account the process of provisioning the other devices and their general product security. One could imagine hardware factory-set and sold in pairs which allowed for backup and recovery, but no additional keys to ever be minted. On the other hand, one could imagine an authenticator where the keys are stored insecurely in the cloud and fully recovered via a single factor. A primary reason for this extension is for input into a risk system. Implementation details like this would drastically alter the perceived strength of the credential and thus how much work is needed to accept it. The only way a risk system can make decisions like this is via attestations. -- GitHub Notification of comment by dwaite Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1691#issuecomment-1019400657 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 23 January 2022 02:45:16 UTC