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:04:16 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-238167715-1470643455-sysbot+gh@w3.org>
Quick responses (to Giri's comments):
regarding a) Agreed.  Changed that in the branch.
regarding b) Agreed.  Changed that in the branch.
regarding c) This is already stated in requirement 1: "More 
specifically, the UVIs used for different rpIds must be uncorrelated".
  Identical values are correlated.
regarding d) I am not sure that this webauthn spec is the right place 
to mandate a specific implementation as this cannot be verified by the
 Web Browser, nor the calling app.  But since this proposal uses a 
rawUVI value which could be computed in an implementation specific 
way, requiring this furmula doesn't effectively restrict 
implementations either (IMHO).  For crypto agility reasons, I would 
just say "secure crypto hash algorithm" instead of mandating SHA256.  
Applicable security certification schemes will typically mandate 
those.
regarding e) This is the part which (IMHO) is relevant for 
implementation flexibility.  There are implementations which use fully
 static biometric templates are ot least some derived data that is 
static (see e.g. https://www.cs.bu.edu/~reyzin/fuzzy.html for 
details).  In those cases the "derived from the biometric reference 
data" is feasible.  
Vijay describes other implementation options in which the biometric 
reference data is dynamically updated and hence doesn't allow the 
derivation of static (i.e. stable) values.  In such cases some GUID 
which is randomly generated but then linked to a verification 
reference data record could be used.  This is what I mean with "(or 
uniquely linked to)".

-- 
GitHub Notification of comment by rlin1
Please view or discuss this issue at 
https://github.com/w3c/webauthn/issues/156#issuecomment-238167715 
using your GitHub account
Received on Monday, 8 August 2016 08:04:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:25 UTC