Overview

Since the commercialization of the Internet in the 1990s, the number of transactions taking place electronically has grown at an astronomical pace, which is continuing today. The issue with electronic transactions is that the party (application or human) at the other end of the transaction often automatically assumes that the transaction should take place and so accepts the transaction.

For transactions where any unauthorized activity can have serious consequences, stronger authentication than just a username and password is needed; ideally at least two-factor authentication needs to be used.

How would it work with iKey?
Whenever something needs to be signed, the system would make a call to an iKey requesting identification. The transaction would not continue until the appropriate iKey has been inserted and the correct PIN entered.

Scenarios for Transaction Based Authentication
As example, let's consider a large university. Take a professor who wants to modify student grades through a web-based portal. When the professor selects the "submit grades" button that will submit grades to the Student Information System through the portal, the application stops the transaction and calls for the insertion of the iKey. Once the PIN is entered and the authentication takes place, the transaction is digitally signed and the Student Information System is updated.

Another example would be a doctor who uses a system that prints prescriptions. The doctor selects the drug and the dosage for the prescription and if the drug is of a controlled class, the system calls for the insertion of an iKey. Following the appropriate authentication, the prescription is printed and the transaction is digitally signed so that the doctor may feel confident that no one can write a prescription using his or her name.