- From: Angelo Liao via GitHub <sysbot+gh@w3.org>
- Date: Sat, 28 Jan 2017 17:03:26 +0000
- To: public-webauthn@w3.org
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