WebAuthn available to Workers? aka "silent authentication"

[equalsJeffH]

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.

[vijaybh]

I suggest moving this out to a v2 of the spec. For v1 I would focus on the core use case of an interactive user in an active browsing context.

[equalsJeffH]

ok, though note that anticipating a v2 augers for us to go ahead and declare the present spec as "level 1".

[equalsJeffH]

note that some folks are equating "silent authn" to "touchless authn"

[equalsJeffH]

see also #22 "Silent/touchless Authn? clarification of bit 0 in AuthenticatorData"

[mikewest]

If y'all have use cases for exposing your authenticators to workers, we can pretty trivially expose the API there. I don't think we'd want to expose the existing credential types to workers, but it's a reasonable thing to debate.

Mind filing a bug against the credential management spec?

/cc @battre

[equalsJeffH]

wrt #199 (comment), see also #475

[equalsJeffH]

@mikewest requested:

Mind filing a bug against the credential management spec?

done. See w3c/webappsec-credential-management#87

[equalsJeffH]

some silent authenticator (aka touchless) discussion is also over in webauthn issue #629.

[equalsJeffH]

some silent authenticator (aka touchless) discussion is also over in webauthn issue #644

[equalsJeffH]

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]

[akshayku]

I may not have understood all the requirements, but from the looks of it, there are some scenarios where user need to authenticate first but can do silent authentication there after for a certain period of time or regularly.

Possibly there can be another scenarios where RP do not have a problem having silent signatures all together and they do not need that first user verified/presence required assertion.

Another set of scenario can be where RP need the guarantee that every signature requires user presence and/or user verification. This is the current default in terms of user presence requirement and provides assurance to the RP that no malware can get silent signatures from the web. This is the requirement for high value keys.

Solution needs to comprehensive for all above requirements although I do not understand scenarios and use cases for it. This is complex and only way I can think of is specifying this behavior for the key at the time of authenticatorMakeCredential and the ability to query this information for the platfrom from the authenticator.

Will all that said, silent signatures from web is a super-cookie for us and is very very dangerous and it brings more harm than good for the whole ecosystem where many RP's will try to think it as a feature without understanding the security guarantees of the choices they are making for their keys. Some RP's maybe willingly try to track user on the web with economic and/or other not good intentions. Being able to get silent signatures basically means that user has its device plugged in to the system or is near by. Cross scripting attacks are also very real from browser pages.

In my view, its not worth it.

[emlun]

I also think silent assertions would open up more and worse issues than it solves. I can see a case for a "keep-alive session" kind of mode where a user confirmed assertion can authorize silent assertions for a specific RP for some amount of time thereafter, but I'm opposed to "super cookie" silent assertions as @akshayku puts it.

[rlin1]

Decision: Keep open, but no immediate action.
Privacy aspect seems difficult to address appropriately. Use case don't seem that relevant for WebAuthnat this time.

[ve7jtb]

To a large extent, this overlaps with token binding. If you do a authentication with the token binding extension you can then token bind a cookie, or otherwise record the token binding ID and check the header on subsequent requests. I understand that token binding is not available on all platforms at the moment. However, I think that is a better way to go than creating a new method of doing super cookies.

[nadalin]

There does not seem to be a clear proposed way to solve the security issues. Need a clear scenario(s) and a PR that we can undestand.

[equalsJeffH]

see also: #1140 (review)

[James-ZHANG]

This might be re-opening an old discussion thread and if that's the case, sorry.

I want to point out one use case where silent authentication would be useful: SSH with SK (see https://www.openssh.com/txt/release-8.2) in web.

In particular, for enterprises using certificate-based SSH, storing certificates inside security keys is a natural design and can be implemented via the largeBlob extension. However, for security, issuance of SSH certificates should require some attestation of the public key. If the enterprise chooses to use, for example, a Webauthn create call to generate the SSH public key and its attestation, setting up an SSH session requires at least two Webauthn calls. The UX would be confusing.

I'm vaguely thinking, if some form of silent authentication is available, we might be able to have a Webauthn-based implementation with much better UX. But of course, the relevant details, especially security implications of any potential changes to CTAP2 for this, need to be carefully crafted.

[ve7jtb]

Ssh can do silent authentication now as it is supported at the CTAP2 level.

ssh has the option to create credentials at credprotect level 3 to prevent them from being used without UV.

I and I expect others would be against exposing that at the WebAuthn level.

Nothing stops someone from modifying openSSH to allow unattended ssh with credentials from a security key.

OpenSSH supports the windows platform authenticator but I don't believe that authenticator exposes silent authentication in the WebAuthn.dll API.

Platform authenticators don't directly support CTAP so not all features are supported.

[nicksteele]

As Tony and John mentioned on this ticket and as others mention on related tickets you can find herein, this is not something we'd like to expose at the WebAuthn layer. I'd like to close this ticket unless there is any interest in continuing discussion on a worker binding for the spec.

[jordaaash]

This might be the wrong place to chime in, I'm sorry if so. A potential value I've been thinking about for being able to create and get credentials from a worker context is that potentially malicious scripts or browser extension content scripts may have access to the window.

Such scripts could either trigger a request to get credentials, which may have associated secrets using prf or largeBlob, or they may be able to intercept these calls or read these values or other information about the credential like the userHandle.

I may be thinking about this wrong, but being able to make these calls from a worker could be beneficial if such scripts have less access.

[timcappalli]

This use case is now being addressed by the Device-bound Session Credentials project (https://github.com/w3c/webappsec-dbsc).