Document prevention of attacks on privacy

index.bs

@@ -4777,6 +4777,88 @@ 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 physical person or a
+correlation of separate identities as belonging to the same physical person. Although the [=Web Authentication API=] does not use
+or provide and form of global identity, the following kinds of potentially correlatable identities 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=], and thus ownership of the [=public key credential=] identified by the [=credential ID=]. They are also visible
+    to the [=client=] in the communication with the [=authenticator=].
+
+- The user's identities specific to each [=[RP]=], e.g. usernames, [=user handles=] and similar aliases.
+
+    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 information, e.g., fingerprints or facial recognition data.
+
+    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, the [=public key credentials=] employed in this specification are designed to be minimally identifying and never
+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 never
+    revealed to other [=[RPS]=]. A malicious [=[RP]=] thus cannot ask the [=client=] to reveal other identities owned by the user.
+
+- 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 having the same [=managing authenticator=]. 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.
+
+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 only used as an additional layer of security for unlocking use of the [=authenticator=]. 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 a different [=[RP]=].
+
+In the case where a [=[RP]=] requires [=biometric recognition=], this is instead achieved by the [=biometric authenticator=]
+setting the [=UV=] [=flag=] in the signed [=assertion=] response. The [=[RP]=] can trust the authenticity of this bit as long as
+it trusts the security guarantees of the [=attestation certificate=] presented when the [=biometric authenticator=] was
+[=registration|registered=].
+
+
 ## 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