W3C home > Mailing lists > Public > public-webauthn@w3.org > August 2016

Re: [webauthn] Clarify meaning of UVI

From: Rolf Lindemann via GitHub <sysbot+gh@w3.org>
Date: Mon, 08 Aug 2016 08:19:46 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-238171020-1470644384-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:22 UTC