Document prevention of attacks on privacy

index.bs

@@ -4777,6 +4777,90 @@ which should make use of the existing browser permissions framework for the Geol
 
 The privacy principles in [[!FIDO-Privacy-Principles]] also apply to this specification.
 
+
+## De-anonymization prevention measures ## {#sctn-privacy-attacks}
+
+[INFORMATIVE]
+
+Many aspects of the design of the [=Web Authentication API=] are motivated by privacy concerns. The main concern considered in
+this specification is the protection of the user's personal identity, i.e., the identification of a human being or a correlation
+of separate identities as belonging to the same human being. Although the [=Web Authentication API=] does not use or provide any
+form of global identity, the following kinds of potentially correlatable identifiers are used:
+
+- The user's [=credential IDs=] and [=credential public keys=].
+
+    These are registered by the [=[RP]=] and subsequently used by the user to prove possession of the corresponding [=credential
+    private key=]. They are also visible to the [=client=] in the communication with the [=authenticator=].
+
+- The user's identities specific to each [=[RP]=], e.g., usernames and [=user handles=].
+
+    These identities are obviously used by each [=[RP]=] to identify a user in their system. They are also visible to the
+    [=client=] in the communication with the [=authenticator=].
+
+- The user's biometric characteristic(s), e.g., fingerprints or facial recognition data [[ISOBiometricVocabulary]].
+
+    This is optionally used by the [=authenticator=] to perform [=user verification=]. It is not revealed to the [=[RP]=], but in
+    the case of [=platform authenticators=], it might be visible to the [=client=] depending on the implementation.
+
+- The models of the user's [=authenticators=], e.g., product names.
+
+    This is exposed in the [=attestation statement=] provided to the [=[RP]=] during [=registration=]. It is also visible to the
+    [=client=] in the communication with the [=authenticator=].
+
+- The identities of the user's [=authenticators=], e.g., serial numbers.
+
+    This is possibly used by the [=client=] to enable communication with the [=authenticator=], but is not exposed to the
+    [=[RP]=].
+
+Some of the above information is necessarily shared with the [=[RP]=]. The following sections describe the measures taken to
+prevent malicious [=[RPS]=] from using it to discover a user's personal identity.
+
+
+## Anonymous, scoped, non-correlatable [=public key credentials=] ## {#sec-non-correlatable-credentials}
+
+[INFORMATIVE]
+
+Although [=Credential IDs=] and [=credential public keys=] are necessarily shared with the [=[RP]=] to enable strong
+authentication, they are designed to be minimally identifying and not shared between [=[RPS]=].
+
+- [=Credential IDs=] and [=credential public keys=] are meaningless in isolation, as they only identify [=credential key pairs=]
+    and not users directly.
+
+- Each [=public key credential=] is strictly bound to a specific [=[RP]=], and the [=client=] ensures that its existence is not
+    revealed to other [=[RPS]=]. A malicious [=[RP]=] thus cannot ask the [=client=] to reveal a user's other identities.
+
+- The [=client=] also ensures that the existence of a [=public key credential=] is not revealed to the [=[RP]=] without [=user
+    consent=]. This is detailed further in [[#sec-make-credential-privacy]] and [[#sec-assertion-privacy]]. A malicious [=[RP]=]
+    thus cannot silently identify a user, even if the user has a [=public key credential=] registered and available.
+
+- [=Authenticators=] ensure that the [=credential IDs=] and [=credential public keys=] of different [=public key credentials=] are
+    not correlatable as belonging to the same user. A pair of malicious [=[RPS]=] thus cannot correlate users between their
+    systems without additional information, e.g., a willfully reused username or e-mail address.
+
+- [=Authenticators=] ensure that their [=attestation certificates=] are not unique enough to identify a single [=authenticator=]
+    or a small group of [=authenticators=]. This is detailed further in [[#sec-attestation-privacy]]. A pair of malicious
+    [=[RPS]=] thus cannot correlate users between their systems by tracking individual [=authenticators=].
+
+Additionally, a [=public key credential=] with a [=Client-side-resident Credential Private Key=] can optionally include a [=user
+handle=] specified by the [=[RP]=]. The [=public key credential|credential=] can then be used to both identify and
+[=authentication|authenticate=] the user. This means that a privacy-conscious [=[RP]=] can allow the user to create an account
+without a traditional username, further improving non-correlatability between [=[RPS]=].
+
+
+## Authenticator-local [=biometric recognition=] ## {#sec-biometric-privacy}
+
+[=Biometric authenticators=] perform the [=biometric recognition=] internally in the [=authenticator=] - though for [=platform
+authenticators=] the biometric data might also be visible to the [=client=], depending on the implementation. Biometric data is
+not revealed to the [=[RP]=]; it is used only locally to perform [=user verification=] authorizing the creation and
+[=registration=] of, or [=authentication=] using, a [=public key credential=]. A malicious [=[RP]=] therefore cannot discover the
+user's personal identity via biometric data, and a security breach at a [=[RP]=] cannot expose biometric data for an attacker to
+use for forging logins at other [=[RPS]=].
+
+In the case where a [=[RP]=] requires [=biometric recognition=], this is performed locally by the [=biometric authenticator=]
+perfoming [=user verification=] and then signaling the result by setting the [=UV=] [=flag=] in the signed [=assertion=] response,
+instead of revealing the biometric data itself to the [=[RP]=].
+
+
 ## Attestation Privacy ## {#sec-attestation-privacy}
 
 Attestation keys can be used to track users or link various online identities of the same user together. This can be mitigated