From the horse’s mouth
The FIDO Alliance and WebAuthN groups are moving towards a password-free authentication approach for online services. This is based around a device-local private authentication key associated with your username for that online service that is only released when you enter your device PIN / screen-unlock code or scan your fingerprint or face where your device supports it. A corresponding public key is stored in the user’s account record on the online service’s servers and used to “test” the private key to complete the user-verification process.
But there is a problem associated with the reality that most of us own multiple computing devices. This can typically manifest in us owning a smartphone, a mobile-platform tablet like an iPad and/or a regular desktop or laptop computer. There is also the fact that most of us will end up owning “connected-TV” equipment be it a smart TV, set-top device or games console that is a gateway to online video services. Or we may even end up using various smart-home platforms including Amazon Echo or Google Home.
The problem also includes lifecycle issues associated with today’s devices such as acquiring a new device or replacing a broken, lost or stolen device. Or it could include where one is using another device on a temporary basis like using a friend’s computer or a computer at a hotel business centre.
Then there is the issue of phishing even with multifactor authentication because there is no way of identifying whether a user is signing in to the real online service or not.
Bluetooth as a means for authentication
One factor being examined is the use of your smartphone as a roaming authentication device. Part of what will be looked at is using Bluetooth LE as a machine-to-machine link between the device you are signing in from and your phone to conditionally release online-service authentication keys.
This avoids you entering a one-time-password in to a phishing site for example because you are not transcribing information in to a site. The Bluetooth functionality is also about device proximity – your smartphone is close to the device you want to sign in from.
I also see the Bluetooth link appealing to client devices that have limited user interfaces like connected-TV devices, printers and the Internet Of Things. It avoids the need to log in to your online service to transcribe a “binding code” to use it with connected-TV devices or, at worst, “hunt and peck” a username and password to associate it an online service.
It will also support bare-bones provisioning to new devices irrespective of the platform such as when you, as an iOS or Android mobile-platform user, want to set up you Windows laptop to work with your online services.
As well, it could come in to its own with temporary-use scenarios like shared computers or equipment installed in places like hotels. It could even include adding one’s online video service account to smart TVs or set-top devices installed in hotels, holiday home or common rooms for temporary use. I could even see this earn its keep as an alternative to cards for authentication at kiosk-type setups like ATMs.
The multi-device approach would be on the likes of Apple, Google and Microsoft coming to the party. This is because it would be based on device operating systems and associated cloud-driven account services like Apple ID (MacOS, iOS, tvOS), Google Account (Android, ChromeOS) and Microsoft Account (Windows, XBox).
In some cases, it may extend to device vendors or other entities who run their own cloud-driven account services and want them as the login of choice for your online world. Even account services typically managed by businesses or education establishments could become “primary” account services typically for large fleets of organisation-owned devices.
This approach would have the operating system create and use the authentication key and store these with your account on the cloud-driven account service. It would come in to its own if you are adding a device that works with the same platform as what you were using, for example onboarding an iPad to the same Apple ID as your iPhone.
The system can distinguish between an extant device and a newer device through another device-bound authentication key that underscores that you are authorised to use the service with that physical device. Here, it can be about deeming that particular new device as trusted and under your control or some corporate setups may use it as a way to constrain use of the service to devices they have control over.
Online services would have to support a number of authentication keys for the same username with these associated with different computing platforms an end-user is likely to use. As well, another requirement that would be expected is to have one authentication key able to work across a vendor’s different operating systems such as a mobile OS and a desktop OS. This is due to vendors architecting their mobile operating systems for battery efficiency while the desktop operating systems are maintained for performance.
Moving between devices or platforms
If you are moving your online life between devices of the same platform, the multi-device authentication would have all the platform-level authentication keys moved across similar to what happens with a password vault app.
The Bluetooth authentication approach will come in to play if you have devices of a different platform. But you have to have one of the devices still alive and in your possession for this to work properly.
What really may happen is that you may use Bluetooth authentication to “enrol” other computing devices and have them seen as trusted devices once one or more of your devices support the necessary standards. Then, whichever one of them that is “alive” like, per se, your regular computer or your mobile-platform tablet would be used to authenticate your replacement smartphone to your secure online circle even if this was to replace a lost, stolen or damaged phone.
If you intend to completely move off a platform, you can simply delete from your online services all the credentials associated with that particular platform. This may be through account management options offered by the online service where you revise what platforms you are logged in from.
Most of us are likely to operate a multiple-platform setup for our online lives. This will typically range from an iPhone and a Windows or Macintosh computer through an Android phone, an iPad and a Windows computer.
Online services will be likely to keep with your username, multiple sets of access credentials for each computing platform you are using. There will still be the ability to keep a platform-specific authentication key for your devices that operate a particular platform along with another for a different platform.
Gaps yet to be filled
One gap that needs to be filled is software-to-software authentication like what is expected for email or document-contribution setups or even the Internet of Everything. Such setups typically rely on stored credentials to authenticate the user with their account on that service along with client software like email clients having continual access to that service.
This may have to be about adapting protocols like IMAP4 or XML-RPC to device-generated authentication credentials and supporting multiple sets of these credentials for one user account. This would be important where multiple client devices are being used for the same online service such as a smartphone and a laptop for an email service.
Even the common reality of users operating multiple devices or using a highly-portable device like a smartphone as an authentication device will not escape the goal of a password-free online-service future. Here it would primarily be about authenticating with a device-local PIN or your fingerprint