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

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

== WebAuthn available to Workers?  aka "silent authentication" ==
As I recall, we've verbally discussed the question of whether the 
WebAuthn API ought to be available to {service, web}workers (aka 
"Workers") but we do not have an issue tracking it as yet AFAICT, so 
here it is. 

The default argument, as I recall, against worker use of WebAuthn is a
 UX one: authenticators, upon receiving a makeCredential() or 
getAssertion() call will signal to the user in some fashion, and since
 workers are asynchronous tasks, this may seem to the user like coming
 out of the blue and be confusing. 

Though, there are a couple of authenticator-behavior notions that do 
not always involve annunciation to the user (see also [1]):

1. for an already-registered authenticator, and an 
already-authenticated session, the RP may wish to 
periodically/asynchronously make a getAssertion() request in order to 
ascertain the continued presence of the same 
device+authenticator+privateKey as was present at the beginning of the
 session, and to do so, using subsequent getAssertion() requests 
without user interaction (because that can become tiresome and 
distracting to the user).   There may be a timeout associated with the
 session which upon expiry causes appropriate user interaction upon a 
subsequent getAssertion() request.  Let's term this "silent 
authentication".

2. for a not-yet-registered so-called "silent authenticator" (the 
authnr has no provision for user interaction itself), and a session 
already authenticated  (either via webauthn or legacy means), the RP 
can send a makeCredential (aka register) request, the user is prompted
 (by the RP or platform) for consent and informed of that the nature 
of this authnr is to not (itself) prompt the user for registration or 
authentication events. If the user gives consent, the authnr is 
registered, and subsequently responds to getAssertion() requests from 
the RP without user annunciation. 

So, if there are use cases where an RP's webapp wishes to employ 
workers, say, to do some sort of background processing, and that RP 
wishes to employ [periodic|asynchronous] getAssertion() requests 
without user interaction (during some allowed time interval perhaps) 
to aid assurance of overall session context continuity, being able to 
employ (1) above may be useful.  


[1] See also the "silent authenticator" notion:
from 
https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-asm-api-v1.0-ps-20141208.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.

from  
https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-authnr-cmds-v1.0-ps-20141208.html#command-description-1:
> 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.






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

Received on Wednesday, 14 September 2016 16:27:11 UTC