Case 1 — A mobile app and offline personalization
A client decides that, given its processes, it does not have the capacity to offer users the ability to manually link a device to their account. At the same time, it operates using just a mobile app, to which a USB key cannot be connected. What’s more, the client does not wish to use any additional devices (such as a Bluetooth authenticator), due to the latter being inconvenient and expensive.
Unfortunately, there are no scenarios of this kind with FIDO2.
Case 2 — PKI integration
The client needs to use a unified solution for authentication and document signing. Document signing should be performed using public key certificates (PKIs). The solution has to work in a mobile app.
FIDO2 is simple and elegant, which cannot be said of PKIs. It is not suitable for the above requirements.
Case 3 — Legal significance
In the financial sector involving remote access to accounts, the legal basis for the processes involving authentication, the usage of different devices, and the confirmation of user actions is an essential element.
The client’s lawyers took the preparations for their own defense against potential conflicts rather seriously and concluded that FIDO2 mechanisms would not constitute an adequate evidence base for a court regarding whether actions had been carried out by a legitimate user.
Case 4 — a telephone operator
The client has a scenario whereby the user carries out actions in the system via telephone, simply by dictating them to the operator. The user should subsequently receive a notification on their mobile phone. They should then read the outcome (whether the operator has correctly specified the relevant details) and confirm it. With authorship and integrity control.
How this can be achieved with FIDO2 without any further support is not entirely clear.
These are just a small sample of the questions that arise when working through individual scenarios for a large service, where real people’s money depends on a combination of convenience and security.
Moreover, FIDO2’s mechanisms offer the same integration pathway as other services for solving tasks related to authentication and transaction confirmation: server-side integration, client-side integration, and the creation of management processes. One positive thing about FIDO2 integration is that, theoretically, a client can replace one server with another or start using new authenticators. I say “theoretically” because implementing standards always has its intricacies.
As for now, the main trend is a shift to mobile and apps. If you’ve got a service that’s slightly more complex than an online store, you can always convert your mobile app into an authenticator. It allows to confirm log-in and transactions content in the service, regardless of the channel that is being used: the web, telephone, a messenger or a mobile app.
Airome Technologies’ PayConfirm essentially offers features similar to FIDO2: reliable, cryptography-based passwordless authentication and transaction confirmation with visualisation. However, given that it is being developed for the finance sector, whereby users manage their money remotely, it accounts for an unlimited number of subtler details and additional requirements posed by security requirements, business subdivisions, lawyers, support, infrastructure, etc., while remaining even more straightforward than the FIDO2 framework.
