Update index.bs

index.bs

@@ -4335,6 +4335,48 @@ The Web Authentication API should leverage the browser permissions framework as
 certain extensions.  An example is the location extension (see [[#sctn-location-extension]]), which should make use of the existing browser permissions framework for the
 Geolocation API.  
 
+# Privacy Considerations # {#sctn-privacy-considerations}
+
+The privacy principles in [[!FIDO-Privacy-Principles]] also apply to this specification.
+
+## 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
+in several ways, including:
+
+- A WebAuthn [=authenticator=] manufacturer may choose to ship all of their devices with the same (or a fixed number of)
+    attestation key(s) (called [=Basic Attestation=]). This will anonymize the user at the risk of not being able to revoke a
+    particular attestation key if its private key is compromised.
+
+    [[UAFProtocol]] requires that at least 100,000 devices share the same attestation certificate in order to produce
+    sufficiently large groups. This may serve as guidance about suitable batch sizes.
+
+- A WebAuthn Authenticator may be capable of dynamically generating different attestation keys (and requesting related
+    certificates) per [=origin=] (following the [=Privacy CA=] approach). For example, a WebAuthn Authenticator can ship with a
+    master attestation key (and certificate), and combined with a cloud operated privacy CA, can dynamically generate per
+    [=origin=] attestation keys and attestation certificates.
+
+- A WebAuthn Authenticator can implement [=Elliptic Curve based direct anonymous attestation=] (see [[FIDOEcdaaAlgorithm]]).
+    Using this scheme, the authenticator generates a blinded attestation signature. This allows the [=[RP]=] to verify the
+    signature using the [=ECDAA-Issuer public key=], but the attestation signature does not serve as a global correlation handle.
+
+
+## Authentication Ceremonies ## {#sec-assertion-privacy}
+
+In order to protect the user from being identified without [=user consent|consent=], implementations of the
+{{PublicKeyCredential/[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)}} method need to take care to
+not leak information that could enable the [=[RP]=] to distinguish between these cases:
+
+- A named [=public key credential|credential=] is not available.
+- A named [=public key credential|credential=] is available, but the user does not [=user consent|consent=] to use it.
+
+If the above cases are distinguishable, information is leaked by which a malicious [=[RP]=] could identify the user by probing for
+which [=public key credential|credentials=] are available. For example, one such information leak is if the client returns a
+failure response as soon as the user denies [=user consent|consent=] to proceed with the operation. In this case the [=[RP]=]
+could detect that the operation was canceled by the user and not the timeout, and thus conclude that at least one of the [=public
+key credential|credentials=] listed in the {{PublicKeyCredentialRequestOptions/allowCredentials}} parameter is available to the
+user.
+
 # Acknowledgements # {#acknowledgements}
 We thank the following for their contributions to, and thorough review of, this specification: Richard Barnes, Dominic Battré,
 Domenic Denicola, Rahul Ghosh, Brad Hill, Jing Jin, Angelo Liao, Anne van Kesteren, Ian Kilpatrick, Giridhar Mandyam,