document and mitigate fingerprinting and disclosure risk of capabilities and extensions #2320
Description
The client’s support or lack of support of a WebAuthn capability may pose a fingerprinting risk. Client implementations MAY wish to limit capability disclosures based on client policy and/or user consent.
We can do deeper analysis than just that it's a risk and that someone could maybe mitigate it.
ClientCapability, but also every extension. Extensions in particular seem very distinguishing, for identifying the particular software configuration that the user has installed for authentication, or maybe other things about the user's underlying software or hardware. The potential risks will change over time depending on which extensions are included in the registry. Does the registry process consider the privacy risks of each particular extension becoming immediately, silently detectable by every origin?
Does 'supported' mean that there are available authenticators or that the platform actually does support it, or just that there is a piece of software that could trigger that functionality if it was configured and called? it isn't clear what this should indicate to the relying party or what the client should be choosing to hide for privacy purposes. Conditions here might limit both the fingerprinting risk, and the risk of revealing details about the user, like their hardware and software.
https://w3c.github.io/fingerprinting-guidance/ has additional advice on how to evaluate and mitigate these risks.
This item was raised and discussed by the Privacy WG as part of this privacy review:
w3cping/privacy-request#162