Re: [webauthn] WebAuthn available to Workers? aka "silent authentication"

fyi/fwiw, UAF supports so-called "silent/touchless authenticators" and has from the beginning. It did not run afoul of the Privacy Principles due to how it is specified.   Here's extracts from the relevant UAF specs:

**UAF specs wrt "silent/touchless authenticators"** -- in the order of "starting at the top and going 'down the stack'" :

**fido-uaf-protocol.html (roughly equivalent to the webauthn spec)**

https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-protocol-v1.1-id-20170202.html#silent-authenticators

[...]
4.1.6 Silent Authenticators
FIDO UAF supports authenticators not requiring any types of user verification or user presence check. Such authenticators are called **Silent Authenticators**.

In order to meet user's expectations, such **Silent Authenticators** need specific properties:
* It must be possible for a user to effectively remove a Uauth key maintained by a Silent Authenticator (in order to avoid being tracked) at the user's discretion (see [UAFAuthnrCommands]). This is not compatible with statelesss implementations storing the Uauth private key wrapped inside a KeyHandle on the FIDO Server.
* TransactionConfirmation is not supported (as it would require user input which is not intended), see [UAFAuthnrCommands].
* They might not operate in first factor mode (see [UAFAuthnrCommands]) as this might violate the privacy principles.

The MetadataStatement has to truthfully reflect the Silent Authenticator, i.e. field userVerification needs to be set to USER_VERIFY_NONE.
[...]


**fido-uaf-asm-api.html (roughly equivalent to a CTAP API)**

https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-asm-api-v1.1-id-20170202.html#security-and-privacy-guidelines

[...]

* **ASMs SHOULD ensure that applications cannot use silent authenticators for tracking purposes**. ASMs implementing support for a silent authenticator MUST show, during every registration, a user interface which explains what a silent authenticator is, asking for the users consent for the registration. Also, it is RECOMMENDED that ASMs designed to support roaming silent authenticators either
  * Run with a special permission/privilege on the system, or
  * Have a built-in binding with the authenticator which ensures that other applications cannot directly communicate with the authenticator by bypassing this ASM.              
[...]


**fido-uaf-authnr-cmds.html (roughly equivalent to an authnr driver API underneath CTAP)**

https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-authnr-cmds-v1.1-id-20170202.html#register-command

6.2 Register Command

[...]
NORMATIVE
[...]
**For silent authenticators**, the key handle MUST never be stored on a FIDO Server, otherwise this would enable tracking of users without providing the ability for users to clear key handles from the local device.

[...]

6.3 Sign Command

[...]
6.3.4 Command Description
[...]
```
8. If number of remaining RawKeyHandles is 1
   [...]
   3.  If TransactionContent is not empty
    * If this is a **silent authenticator**, then return UAF_CMD_STATUS_ACCESS_DENIED
   [...]
   4.  If TransactionContent is not set, but TransactionContentHash is not empty
     * If this is a **silent authenticator**, then return UAF_CMD_STATUS_ACCESS_DENIED
   [...]
```
NORMATIVE
[...]
**Silent Authenticators** MUST NOT operate in first-factor mode in order to follow the assumptions made in [FIDOSecRef].



[end extracts]

-- 
GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/199#issuecomment-341576776 using your GitHub account

Received on Thursday, 2 November 2017 22:27:45 UTC