How do I use a smart phone as an authenticator in the new Web Authentication specification?

Question

I have been learning about the new Web Authentication specification. I am a little confused as to how the following use case would work:

A user wants to login to an enterprise web application on their laptop or desktop, using their smart phone as an authenticator (as defined in the spec).

To clarify... the user would type in their username in the web application running in the browser on their laptop. They then click a button that says something like "Password-less Login With Smartphone". They would then click this button at which point they would be prompted on their smartphone for a fingerprint scan. Upon a successful scan they would be logged in to the site. This flow is outlined as an example workflow in the specification here. Also, Google did a nice presentation where they gave an example of something similar except that the web application they were running was already running on the smart phone (not a desktop or laptop). See here. I am interested in the use case where a user is running a web application on their laptop or desktop and want to use their smart phone as the authenticator.

This leads me to the following question(s):

At a high level, what is the process for setting up a smart phone as an authenticator? Is it possible to do this? Is this a use case that Web Authentication supports?

What I am looking for is a very high level of how somehow should setup the browser to interact with their smart phone the same way it would when using Yubikey or another similar device. All of the examples I have seen use Yubikeys or other USB devices as the authenticator for this particular use case, not a smart phone. Any insights would be helpful.

Answer 1

According to the (non-normative) introduction:

Other authenticators MAY operate autonomously from the computing device running the user agent, and be accessed over a transport such as Universal Serial Bus (USB), Bluetooth Low Energy (BLE) or Near Field Communications (NFC).

So the client (browser) communicates with the authenticator (smartphone) using USB, BLE, or NFC using the Client to Authenticator Protocol (CTAP).

I'm not aware of any smartphone authenticator implementations as of yet, and no current browsers support connecting to an authenticator over BLE or NFC. This indicates bluetooth support was planned for Chrome 68, but I haven't seen any more recent mention of it.

Update: As noted here, Chrome 72 includes BLE support for authenticators that can be enabled by a flag.

Answer 2

You will need to have some app on the smartphone that will hold your credentials, not your password.

As soon as you try to login, the site backend will have to push a message to the smartphone with a special request code, and the application will display a message with the site, and probably timestamp and browser data (browser type and OS, at least). When you acknowledge the login attempt, the app sends back the credentials and the site lets you log in.

Possible? Yes, no technical challenges on this. Google uses (if you set it up first) something like that on 2FA: it pushes a message on your phone every time you try to login on a new device. The problem is to find the Trusted Relaying Party that will stay in the middle between your site and your client's smartphone. Unless there are only a few ones, nobody will use, as every user will have to install dozens of authentication apps to use their sites. Users will all use the same password on every service, or login with Facebook...

Answer 3

All Cases i know and also use, use a fqdn for mfa/2fa. Which means if you try to setup such service on a Notebook, this device has to be always reachable to and frpm the internet always on the same fqdn. Than this wan't be a Problem. As for example some DynDNS service installed on and updating the IP of this Maschine.