W3C home > Mailing lists > Public > public-webauthn@w3.org > September 2017

[webauthn] Privacy Considerations should describe risks of storing userID/displayName in "second-factor" authenticators

From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
Date: Wed, 20 Sep 2017 18:08:55 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-259252933-1505930924-sysbot+gh@w3.org>
jyasskin has just created a new issue for https://github.com/w3c/webauthn:

== Privacy Considerations should describe risks of storing userID/displayName in "second-factor" authenticators ==
After discussions about #558, there's agreement that in cases where the authenticator doesn't itself authenticate the user (e.g. via PIN, fingerprint, etc), it's a bad idea to store PII in the authenticator. The PII appears to be all of [MakePublicKeyCredentialOptions.user](https://w3c.github.io/webauthn/#dom-makepublickeycredentialoptions-user) except perhaps for `id` if the RP is careful (see below).

The RP is required to pass all of these fields to `create()` operations, so we should advise authenticators to avoid returning the non-`id` ones unless the authenticator has evidence that the same person is retrieving the fields as stored them.

We should also give guidance to RPs about what to store in user.id to make it minimally identifying. @leshi suggested that the RP should aggregate the ID with a random nonce and encrypt that with a key secret to the RP, so that people with access to the authenticator get what looks like random data.

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/578 using your GitHub account
Received on Wednesday, 20 September 2017 18:08:50 UTC

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