Re: WebAuthn Level 2 is now in CR

Please find my comments below.

> Here is the link to the Level 2 Webauthn CR Web Authentication: An API 
> for accessing Public Key Credentials - Level 2 (w3.org) 
> <https://www.w3.org/TR/2020/CR-webauthn-2-20201222/>
>
> The WebAuthn WG can issue a CfC to move to Proposed Recommendation 
> after the CR comment period closes 19 January, and publish the PR for 
> AC review on 9 February if we chose to do so.
>
> Thanks to everyone for helping get to this milestone, and Wendy and 
> John for working on the CR package.
>
I browsed through this draft document and I have a few comments.

*1) General comments* :

This document is hard to read and to understand since it is lacking an 
overview.

The document looks more like an implementation guide to be used by 
programmers only.

The document includes many options/possibilities that should be 
presented and explained in a single place.

The differences with FIDO U2F are scattered through the document and are 
not sufficiently explained.
An informative Annex would be welcomed.

*2) *Section 13.5.6 (about *Credential Loss* and Key Mobility) states*:
*
       This specification defines no protocol for backing up credential 
private keys, or for sharing them between authenticators.
       In general, it is expected that a credential private key never 
leaves the authenticator that created it. Losing an authenticator 
therefore,
       in general, means losing all credentials bound to the lost 
authenticator, which could lock the user out of an account if the user
       has only one credential registered with the Relying Party.

*This is the **Achilles' heel of this draft*. From an "ease of use" 
point of view, the lack of the ability to perform a back-up copy of an 
hardware authenticator
is not acceptable for the users. Registering multiple authenticators, as 
suggested in a Note, is not an appropriate solution. A user should be 
able to perform
the backup of an hardware authenticator under the condition that only 
one hardware authenticator can be made active at a given instant of time.
Such a back-up mechanism is technically feasible but mandates the 
definition and the development of an additional architecture.
Without this additional architecture, many (if not most) users will 
refrain to use FIDO.

_Note_: If back-up devices are being used, the use of the "signature 
counter" by Relying Parties should be deprecated. Its use is left at the 
discretion of Relying Parties.

*3) *The definition of the term " Virtual Authenticator " is missing is 
section 4 (Terminology). It only appears for the first time in Sections 
11.1 and 11.2 together
with "extension commands". It is supposed to be a piece of software, but 
its implementation is unclear: "Virtual Authenticators are stored in a 
Virtual Authenticator Database".
The term "Virtual Authenticator Database" is also left undefined. What 
is the relationship with an hardware authenticator ? What about the 
user's mobility ?

Section 11.7 defines a "Remove Credential" extension command which is 
interesting from management purposes. Is this command mandatory to 
implement ?/
/
*4)* An authenticator is able to locally store a set of data for 
each//Relying Party Identifier (rpIdHash). The management functions for 
this set of data are not clearly identified.
 From a user point of view, there is the need to be able :

  * to know approximately the numbers of entries that can be locally
    stored into an hardware authenticator, (a) before buying it and (b)
    when using it, and
  * to remove "old" entries that have not been used for a long time
  * to identify the URL associated with each entry.

For the first need, when users buy an hardware authenticator, they 
should be able to approximately know how many entries can be stored in 
that authenticator.
The current document does not help since it only talks about a "byte 
array of 37 bytes or more". When the authenticator is being used, it 
does not seem that
there exists an API or a command retrieving data that allow to compute 
that information.

For the second need, two items would be needed:

  * a "last-used date" that would be added (and updated) for each entry, and
  * a delete entry API or command (can the"Remove Credential" extension
    command be used ?).

It would be particularly useful to support a "last-used date". Although 
WebAuthn Extensions are being defined, these kinds of extensions do not 
seem
to be appropriate since they are only intended to be used by Relying 
Parties.

For the third need, it is well understood that the rpIdHash is shorter 
than a URL, but it is not meaningful for a user.

How can a user recognize that he does not use any longer a given URL ? 
Some guidance about the surrounding software of the (i.e. the client) 
should be given.
It is suggested to allow to support the full URL and the "last-used 
date" at the level of the API but to leave some flexibility how it may 
be implemented.

For example, if the authenticator has a large memory, these two items 
would be supported by the authenticator itself.
On the contrary, if the authenticator has a small memory, these two 
items would be supported by a "shadow authenticator" that would be 
stored by the client in a file.

*5)* Authorization Gesture, User Consent and Test of User Presence

As explained in the draft:

    An authorization gesture is a /physical interaction/ performed by a
    user /with an authenticator/.
    An authorization gesture is a ceremony component often employed to
    indicate /user consent/.
    A test of user presence is a simple form of authorization gesture
    and technical process where a user interacts with an authenticator
    /by (typically) simply touching it/ (other modalities may also exist).

These sentences prevent to use a component like a cryptographic SD card 
that would be inserted into a smart phone or a laptop.
An interaction with a smart phone or a laptop (instead of the 
authenticator) should be possible.

It would be interesting to understand when and how the user consent 
would be obtained when the user is using the smart phone or the laptop
instead of a physical button placed on the authenticator.

*6)* There are some empty sections where text should be added:

  * 13.4. Security considerations for clients
  * 14.5. Privacy considerations for clients

*7)* There is a typo in Section 1.1: "expecially".

Denis