- From: Akshay Kumar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Sep 2017 14:44:14 +0000
- To: public-webauthn@w3.org
Cross posting here: > The user id is no more PII than the credential ID -- both map uniquely to the user > CredentialID is also PII. I'm not sure there's any difference in something that's in plaintext or need to be looked up in a DB (by the RP). Most RPs (including Google) can't key off of CredentialID and requiring this will be a major impediment to implementing this protocol (not only for us). I do not think this is correct. CredentialID does not reveal anything about the user. It may be unique in RP's database but credentialID by itself doesn't reveal any information about the user to the attacker. On the other hand, for userid, RP's can have any string which potentially identifies the user. For example, Email-ID or something. So User id in current form is definitely a PII. > It's not about our implementation -- I honestly believe that the spec will have difficulties with adoption of the single factor use case when the first caveat is: "you need to re-index your database". Although MS implemented credentialID based lookup, it was some effort to achieve this so I understand the sentiment here. On a sidenote that may or may not be relevant here, for single account per RP case, I am not sure what value any of the user fields give. Instead RP can just omit it out or have constant strings. This is also applicable for extremely security conscious RP's who don't want to reveal anything even in case of hardware attacks. The purpose of passing user id to the authenticator is that the authenticator should not create multiple credentials for the same user id and should overwrite the existing one if applicable. Its purpose is not to be used in account selection. For account selection, we have name and display name fields. Thinking more about this, there can be two kinds of RPs. One who care about privacy and does not want user id getting returned in authenticatorGetAssertion and the one who don't care. **Proposal:** (Only reason this can be considered is to reduce the work of rekeying the database. Otherwise, there is no reason.) For the case of RP who does not care about privacy of user id and want to use user id lookup in the database or can do credentialID lookup, it will use real user id at the time of authenticatorMakeCredential. For the case of RP who cares about privacy of user id and can do credentialID lookup in the database, they can pass SHA-256(userid) at the time of authenticatorMakeCredential. For the case of RP who cares about privacy of user id and still wants to use user id lookup in the database: put encrypted user id with decryption key in their database or tough luck. -- GitHub Notification of comment by akshayku Please view or discuss this issue at https://github.com/w3c/webauthn/issues/556#issuecomment-329190564 using your GitHub account
Received on Wednesday, 13 September 2017 14:44:22 UTC