[webauthn] Add clearer definition of API use cases to the spec

AngeloKai has just created a new issue for 
https://github.com/w3c/webauthn:

== Add clearer definition of API use cases to the spec  ==
The current use case section of the API has two main sections: 
registration and authentication. However, in reality, the API can be 
used for a number of means and uncertainty has led to confusion among 
developers we talked to. A clear definition would help us in guiding 
our work and give developers clear idea of what the API can do. I 
think the list below seems like a good starting point: 

- **Two factor - first login (bootstrap)**
  - Description:
      - The API can be used when a user logs in to a new machine for 
the first time. Typically a site requires the user to provide extra 
info to verify and then the user can use password. USB devices can be 
used to provide the extra info to verify the user’s identity.
  - Attributes of the authenticator devices used in this case: 
      - The device must be portable*.
      - The device doesn’t need to be positively identifiable**.

- **Two factor - always**
  - Description: 
      - The API can be used when a user logs in to a site that always 
requires password and second factor.
      - For example, after a user opts in to use U2F devices at 
Github.com, s/he is always required to type in password as well as 
plugs in a U2F device whenever s/he logs in.
   - Attributes of the authenticator devices used in this case:
      - The device must be positivity identifiable.
      - The device can be portable or built-in. 
        
- **Password-less Re-auth**
  - Description: 
      - User created a account along with a password saved on the 
server. However, the user doesn’t like having to type in password 
every time and opts to use an authenticator. 
  - Attributes of the authenticator devices used in this case: 
      - The device must be able to positively identify the user. 
      - The device can be either portable or built-in, though built-in
 authenticator likely most useful here, such as fingerprint reader, 
facial recognition. 

- **Password-free accounts, first login (bootstrap)**
  - Description: 
      - Unlike the case above, the user never has a password saved on 
the server in this case. When a user signs up, s/he used an 
authenticator and never used password to log in before. 
  - Attributes of the authenticator devices used in this case: 
      - The deice must be able to positively identify.
      - The device must be portable 

- **Sign in without user name**
  - Description:
      - User never created even a username in this case. The user is 
given a device at some point and is told to always use this device to 
log in. 
      - For example, a IT or retail employee uses NFC to login to site
 to punches in and out, record sick days, etc. 
      - The above example assumes the device is only used within a 
organization. However, this is not to say the case can only exist 
within enterprise scenarios. It is possible user ends up always use an
 authenticator to logs in. Then this leads to the problem of whether 
we want capabilities to the API in case a device’s memory is full.
   - Attributes of the authenticator devices used in this case: 
       - The device must be portable
       - The device must be able to produce assertion without user 
name, only RPID

*: An example of a portable device would be a use key or a phone that 
the user can carry around and use to logs in to any place. An example 
of a built-in authenticator would be Windows Hello or Android 
fingerprint scanner. This is not to say they are always going to be 
entirely different devices. 
**: There seems to be two category of devices: devices that can 
identify users through biometric means, such as fingerprint scanner, 
and devices that can’t, such as a number of Yubikeys that use the 
click of a physical button as confirmation of user intent without 
additional identification means. For now, I call devices of the former
 category as devices that are positively identifiable and the latter 
as devices that aren’t. 



Please view or discuss this issue at 
https://github.com/w3c/webauthn/issues/334 using your GitHub account

Received on Saturday, 28 January 2017 17:03:49 UTC