- From: Rolf Lindemann via GitHub <sysbot+gh@w3.org>
- Date: Fri, 05 Aug 2016 14:42:43 +0000
- To: public-webauthn@w3.org
new proposal: The user verification index (UVI) is a value uniquely identifying a user verification data record. The purpose of the UVI is to let a FIDO Server understand whether an authentication was authorized by the exact same biometric data as the initial key generation / makeCredential. This allows the detection and prevention of "friendly fraud". Requirements for the UVI: Privacy preserving. The UVI may not leak any sensitive information which could be used as a correlation handle. More specifically, the UVIs used for different AppIDs must be uncorrelated, so that RP1 cannot make sense of the UVI values received by RP2. This also means that it must not be possible to derive/re-construct the biometric data from the UVI. Uniquely linked to one biometric and key. 2a: If two UVI values for one public key are identical, this MUST mean that exactly the same user verification data record was used for unlocking the key). 2b: If two values are different it MUST mean that the biometrics (or the key) are different. As a consequence of 2a, a UVI value used for one key can never be re-used for a different biometric, e.g. if UVI for the left index finger is X, then this X might not be re-used for any other finger - regardless of how often the user deletes and enrolls fingers (without irreversibly destroying the related private key). We recommend computing the UVI as follows: UVI = SHA256(PublicKey | rawUVI), where publicKey is the related public key of the scoped credential generated by the authenticator and where rawUVI is derived from 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. It is important that the authenticator doesn’t leak the rawUVI as it is a global correlation handle. Notes (won't go into the specs): Why not just returning an enrollment counter of the biometric (e.g. 1 for the first enrolled finger, 2 for the second one etc.)? It is not guaranteed that the user doesn’t enroll one finger twice, e.g. at position 1 and 2, violating requirement 2a (same biometric must lead to same UVI for same key). The user could enroll some fingers, then delete the first one and re-enroll the finger originally enrolled for at position 1. Violating requirement 2a (same biometric must lead to same UVI for same key). The UVI in this case would be an enrollment counter leaking some bits of entropy for correlating users. Violating requirement 1. -- GitHub Notification of comment by rlin1 Please view or discuss this issue at https://github.com/w3c/webauthn/issues/156#issuecomment-237869041 using your GitHub account
Received on Friday, 5 August 2016 14:44:47 UTC