I'm requesting a TAG review of:

• Name: Web Authentication Feature Detection
• Specification URL: https://github.com/w3c/webauthn/pull/1219
• Primary contacts (and their relationship to the specification): @jafisher-microsoft, although commenting on the public pull request is probably best.

Further details:

• Relevant time constraints or deadlines: Web Authentication WG is likely to decide whether to land the PR in the coming weeks. It would then be in the pipeline for WebAuthn Level 2 Draft 2.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: Web Authentication

Background

The Web Authentication specification (“WebAuthn”) allows the use of security keys (a.k.a. “U2F” keys or “FIDO” keys) on the web. Different browsers have different levels of support for various features but, in level one, there was a single, ad-hoc feature-detection interface to signal whether a built-in user-verifying authenticator was configured. (E.g. Touch ID on some Macs.)

However, web sites wish to provide smarter experiences based on the features supported by a given browser, and grubbing around in the User-Agent header is unpleasant and fragile. Working along the lines of the relevant design principle, there is a proposal to add a more featureful detection interface in level two.

The WG is aware that feature-detection is a subject that has some history in web standards and are seeking input sooner rather than later.

The following is a personal perspective, but might still be helpful background:

The concerns here are not so much from a privacy perspective. For the single existing feature-detection call in level one, Chromium reasoned that the information exposed was little more than could be gathered from browser version and rough hardware device—information that web sites can generally obtain already. Likewise, with the proposed interface, the information does not seem to be more than a detailed database of User-Agent strings and a little probing with Javascript could figure out anyway. So the uncertainty in the WG is more around whether there are strong opinions in the web community about this topic in general that we should be aware of.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review. (Actually, feedback on the PR would keep things together.)
• leave review feedback as a comment in this issue and @-notify [github usernames]