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

Re: [webauthn] Clarify meaning of UVI

From: gmandyam via GitHub <sysbot+gh@w3.org>
Date: Sun, 07 Aug 2016 16:20:48 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-238091693-1470586845-sysbot+gh@w3.org>

Thanks for putting this together.  Some questions/comments:

a)  "Privacy preserving. The UVI may not leak any sensitive 
information ...".  IMO is requirement is not a "may" but a "MUST".  
Note that certification programs will likely take adherence to privacy
 guidelines such as those from IDESG [1] into account.

b)  "the UVIs used for different AppIDs must be uncorrelated".  I 
don't think we are contemplating AppID in this specification (although
 it could have some relevance to the intersection of Webauthn and 
installable apps, e.g. Apache Cordova).  Recommend sticking to RP ID.

c) "If two UVI values for one public key are identical" - similar 
comment as b).  The UVI values should be scoped to the RP ID.  Two UVI
 values should never be identical across RP ID's even if they 
correspond to the same biometric.  The public keys generated for a 
given biometric will not be identical across RP ID's as per the spec, 
but the UVI text should restate this fact in order to prevent 

d)  "We recommend computing the UVI as follows: UVI = SHA256(PublicKey
 | rawUVI),"  Why not make this a normative requirement rather than a 
recommendation?  It will make certification/interop more feasible, and
 ensure that personally-identifiable info isn't being packed into the 

e) In addition, I think we should provide rules for generating rawUVI 
beyond "rawUVI is derived from (or uniquely linked to) the biometric 
reference data such that different biometric reference data leads to 
different rawUVI values and identical biometric reference data for the
 related user lead to identical rawUVI values."  We should at least 
plan for the day when SHA256 hashes can be cracked.  Providing 
normative guidelines on the calculation of rawUVI so that it doesn't 
leak linkable personally identifiable information is a possibility.  
One suggestion:  rawUVI = RPID |( Biometric mode GUID), where 
(Biometric mode GUID) is never leaked from authenticator.  We can also
 place rules around generation of a GUID to allow for cancellable 
biometrics, i.e. re-enrollment always results in a generation of a new
 GUID even if it is for the same user re-enrolling the same biometric.


GitHub Notification of comment by gmandyam
Please view or discuss this issue at 
using your GitHub account
Received on Sunday, 7 August 2016 16:22:54 UTC

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