In the last episode of
<517f820d$0$64324$c3e8da3$
5e5e...@news.astraweb.com>, JF Mezei
<
jfmezei...@vaxination.ca> said:
>On 13-04-30 03:02, DevilsPGD wrote:
>
>> True, if you limited yourself to NFC. Payment processing could be done
>> more easily for data-connected devices by having the device scan a QR
>> Barcode to retrieve the data required to start the process, and have the
>> confirmation be transmitted in return online when possible, falling back
>> to Bluetooth only when needed.
>
>Not gonna happen.
>
>Current systems as setup in Canada by CIC/Rogers and the coming Interac
>ones do not use the internet connection at all for the transaction. Not
>only insecure, but also involves the wireless carrier in the transaction
>(which means banks have to share transaction costs with the carrier).
It's not insecure unless it's designed incorrectly. Now admittedly
Apple's approach to security isn't consistently good, but there's no
reason that this would need to be difficult.
A very simple implementation would take a request from the merchant with
the following details:
Merchant information:
Merchant ID Number (already public, no privacy risks)
Acquiring Bank ID (already public, no privacy risks)
Date and Time (already public, no privacy risks, prevents replay
attacks)
Transaction information:
Transaction ID (GUID or similar, generated randomly per-transaction, no
transaction details, therefore no privacy risk)
Amount
Type (preauth, purchase, refund, etc)
Currency Code
The device would receive the above information in a QR code, the user
would approve it, and the device would then sign this information and
transmit only the merchant information, customer identifier, transaction
ID and digital signature to the processor. With creativity this could
fit into 1 SMS.
The processor would then confirm that the account is authorized, has
funds available, etc, and would transmit the confirmation to the
merchant over traditional channels.
Because this is a pure software solution, it can be easily upgraded,
both for security and for convenience. For example, you might want to
add a tip entry into the device's UI, or the ability for the merchant to
specify multiple prices or a range from which the customer can choose
(for example, at a gas bump, where you might be allowed to preauth
anywhere from $5 to $150 per transaction), or you might add cash-back
options to appropriate transactions.
There's also no reason to share anything with the carrier, wrap the
whole thing in a HTTPS tunnel through Apple's existing networks when
connecting wirelessly, or connections directly to the merchant terminal
requiring an Apple signed SSL certificate for the handshake.
Although your personal ID (roughly equivalent to a credit card number)
would be transmitted, the ID itself would be meaningless without the
digital signature, and therefore not a security risk.
Since the device's communication with the processor is very minimal, it
could be done over SMS, cellular data, Bluetooth*, Wifi*, by having the
merchant scan the screen, or even high frequency audio.
*Bluetooth: Merchants would use a dedicated Bluetooth UI that would
accept connections from devices and only allow communication with
merchant providers, so there would be no separate pairing process
visible to the user, and the scanned QR code would indicate the
availability of Bluetooth, would include the BT device identifier and
PIN.
*Wifi could be handled the same way, using the store's own wifi for
non-cellular connected devices, but this could also be done using the
store's public wifi if the device is already connected to such.
Since it's all done in software, the device could contain multiple IDs
and signing certificates, they could be rotated automatically based on
privacy (so not even a merchant could identify repeat purchases from a
single account) and security needs (all encryption keys should be
rotated, the speed at which this is done is based on cypher strength)
This scheme would require that the merchant be online at all times or
willing to cache transactions for later processing (which is how things
currently work anyway). For businesses willing to rely on customer data
plans or SMS, it wouldn't need any additional hardware (assuming their
POS is actually computer driven, with a printer that can print a
bitmapped QR image -- Any business that can put a logo on their receipt
has the right printer already), but for businesses willing to invest in
a Bluetooth adapter or wifi, it would immediately scale to iPod Touches
and non-data-connected devices.
Heck, even most Java-capable dumb phones could get in on the action, if
the phone has enough CPU power to process a QR code in the Java VM and
Java apps can access the camera in real time (a whole lot of big IFs
here)
If you were to partner with a few large names (something Apple has the
power to do) along with an up-and-coming payment processor like Square
(to bring a massive number of small vendors online overnight), you might
make something that would work.
Best of all, since QR codes can be printed, they could be on the bottom
of receipts at restaurants allowing you to pay from the table without
waiting for the waitress to wander by with a terminal (And without your
card leaving your hand, for countries that still use magnetic stripes)
>By using NFC, the transaction is between the phone and the paypass
>terminal without involving the wireless carrier at all. It uses the same
>network as with normal credit card, nothing special done by banks for it.
That's how it's done now, yes. I'm suggesting inventing something new,
not building on the current NFC system.
>(the wireless carrier is involved in the provisioning of the encrypted
>blob of credit card to storage on SIM card, but not in the actial
>transactions).
And the fact that wireless carriers are involved at all is a potential
problem, when/if NFC takes off. Imagine wireless carriers start wanting
a piece of the transactions or they refuse to provision SIMs?
>If Aple wants to be different, it will become its own bank and use its
>existing relationship with millions of customers so tat when you use
>your iPhoe to make NFC purchases, it gets biled to your Apple account.
I could definitely see Apple going that route. But I could also see them
wanting a larger deployed base than only the latest and greatest model.