- From: Johan Verrept via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Sep 2017 17:13:01 +0000
- To: public-webauthn@w3.org
Credential IDs are not guaranteed unique in any way. Unless I missed something in the specs, it is perfectly valid to store all data locally and return a single byte key index. This has a lot of consequences that are not currently handled, especially in the RP assertion validation algorithm: * a Credential ID is not guaranteed unique for a single user on a single RP. (Will happen if you buy two such authenticators and you register them as a pair on every account). * You cannot refuse duplicate Credential IDs as this is both valid and, if such an authenticator becomes popular, likely to be relatively common (as all credential IDs will be in the same limited range). Refusing would put the user in a situation he cannot resolve, retrying the registration will just replace the current key entry (as specified) with likely the same index. * You need to verify against the public key of every matching Credential ID for this user. If one matches, this is a valid assertion. It also makes returning the User ID a necessity as you would have potentially thousands (millions) of accounts with this Credential ID for first factor scenarios. In any case, the specs assume Credential ID collisions are at least unlikely. It might be easier to add a few requirements to promote that than try to handle all the issues. I've raised an issue for this in the FIDO group. Should I raise one here too? -- GitHub Notification of comment by jovasco Please view or discuss this issue at https://github.com/w3c/webauthn/pull/558#issuecomment-331221936 using your GitHub account
Received on Thursday, 21 September 2017 17:12:53 UTC