If certain voices in the computing industry are to be believed--including Google, Apple and Microsoft--the future of personal payments will be near-field communication (NFC) via cell phones. Credit cards will become a forgotten memory, and all we'll do to authorize a payment is tap our handset against a reader device on a store counter before carrying away our shopping.
However, research from Oracle has rained on the parade. Oracle imagined a real-life scenario in which a user is paying for goods but also expects his or her loyalty account to be updated, and is also trying to cash a coupon. That's three transactions in total, with all the data originating on the handset.
According to Oracle, an average file read takes roughly two seconds--enough to fall feasibly into the definition of a tap. But six seconds is therefore required for the demo three-file transaction, a length of time leading to a process Oracle tartly calls "tap and hold."
The two-second transactions were for simply reading data. If data is to be written to the device, such as deleting a coupon that's just been cashed, then it takes even longer.
Stand up, grab your phone, and hold it against something for eight seconds to see how it feels. Personally, I wouldn't use the word "convenient," and I'd be much happier to punch in a PIN or even sign a piece of paper. Even worse, if the individual moves their phone away from the receiver while the transaction is taking place, it fails and everything must start all over again.
One can imagine NFC terminals requiring the user to place their phone on a special plate while the transactions take place. We can also easily imagine the customer walking off and forgetting to pick up their phone.
As a solution to the speed issue, Oracle suggests the phone contains a hash code, which is checked against a back-end database (quelle surprise, considering Oracle's in the database business). Therefore, the back-end computer does all the work. However, this would mean every NFC terminal in every shop would have to be permanently online--not infeasible in our modern world, but adding a new layer of potential insecurity as well as complication.
Additionally, if all that's being handed over are hashes, you might as well use a bog-standard smartcard. NFC promises to offer so much more. For example, last year former Google Chief Exec Eric Schmidt talked of users being sent coupons for products based on their location, or being to tap the card on local placards to download local information.
Oracle hasn't described the nature of its test setup, and a key issue is whether the data was stored on the card's SIM chip--something known as Single Wire Protocol, wherein the phone's computer is essentially bypassed--or in the phone's software. SIM chips are designed around security and are old technology, so may have been the slowest link in the chain. Retrieving files from the phone's memory, and encrypting and decrypting them in software on a modern phone should be almost instantaneous, especially if the NFC software is kept running as a background process.
Oracle's research indicates how many bugs there are yet to work out before NFC payments become mainstream. Despite Google's push for us to take up NFC, it would be a huge shame if NFC were rolled-out too early and was rejected by consumers as not delivering on its promises of fuss-free purchases.