- From: Rolf Lindemann via GitHub <sysbot+gh@w3.org>
- Date: Mon, 08 Aug 2016 08:19:46 +0000
- To: public-webauthn@w3.org
Response to Vijay's comments: a) For example, a user who has enrolled a particular finger and been using it, and then decided to delete and redo the enrollment (perhaps because it is not working so well any more). Approaches like https://www.cs.bu.edu/~reyzin/fuzzy.html claim that in most (not all) cases re-enrolling the same biometric would lead to the same rawUVI. There might be some that don't, in which case it is up to the RP to decide how to handle that. (There will still be other authenticators not supporting UVI at all, so the RP needs a way to handle non-matching+missing UVIs). b) For instance, in case of a UVI mismatch, does the RP ask the user to proof up? In most existing deployments there is still a username+password (or a user's PIN), But using FIDO is significantly more convenient. If the RP is interested in knowing whether I (or my son playing with my device) is triggering a high value transaction, they might ask be for a password/PIN if UVI doesn't match/isn't supported. In a low value transaction they might just increase some internal risk score in which it finally depends on other parameters whether additional verification measrues will be requested. I think understanding at least one possible flow is important, I am not sure we want to add such to the web authn spec. c) At a higher level still, I'm still not sure how to ensure this does not become a way for the authenticator to pass 32 bytes of whatever it wants to the RP I share this concern. But what's the alternative? Security certification schemes might include controls for that. -- GitHub Notification of comment by rlin1 Please view or discuss this issue at https://github.com/w3c/webauthn/issues/156#issuecomment-238171020 using your GitHub account
Received on Monday, 8 August 2016 08:21:59 UTC