By Sarah Clark | May 11th, 2011 "I'd love to see peer-to-peer used for payment," Google's Nick Pelly told a packed audience at the I/O conference's 'How to NFC' session, as he responded to questions regarding the future of mobile payments on Android devices. PELLY: 'Hoping that everyone will just move to peer-to-peer or ndef exchange' At a session at the Google I/O developers conference in California that was devoted to NFC yesterday, Google's Jeff Hamilton and Nick Pelly, engineers working on the Android NFC stack, explained some of the issues surrounding the ability to include mobile payments on NFC devices — and cast doubt over the long term viability of card emulation mode as the way ahead. At the end of a detailed presentation outlining how Android NFC phones can be used for tag reading, writing and peer-to-peer applications, Pelly turned to the question of mobile payments: So we talked a lot about read or writer mode and peer-to-peer. There's a third major mode of NFC, which is card emulation. This is when the Nexus S is pretending to be a passive tag that you can put in the field of a reader/writer. So if you wanted to pretend to be a transit card or pretend to be a credit card. So in Gingerbread, we have no API support for card emulation. And it's not that we forgot. We thought very hard about it. But there's some simple reasons. I showed you that diagram earlier of all those different technologies. Well, if you're going to do card emulation, the hardware has to pick one of those technologies to emulate. You can't typically emulate all of them at the same time. And the hardware out there today doesn't actually support all of these at the same time anyway. So if we were to build these APIs, the applications are going to have a really inconsistent experience as they're deployed to different Android devices. Some will support NFC-A, some will support NFC-B. We don't think this is really going to be a great story for third-party developers right now. And secondly, when you're doing card emulation, you're emulating a passive target that is going to have one kilobyte, two kilobytes of memory. You're going to then have to decide which application has the right to manage this limited resource. So we did not put card emulation APIs in Gingerbread because we want to make sure that we have a compelling user story before we do that. And we really think that peer-to-peer is the way to go for future NFC uses. Peer-to-peer and ndef, because with ndef you can filter on content. And with peer-to-peer, it's a newer technology. It doesn't have to assume that one side is passive." In a question and answers session following the main presentation, the issue of mobile payments was raised again and Pelly provided further details of Google's concerns: The problem is that the hardware out there today, you know, if you buy an NFC controller, it typically is only going to be able to emulate one of those RF-level technologies. So as an application developer, you don't know which — when it's getting deployed to a phone, which one is on the phone. So I guess until we see the industry standardize around maybe one RF-level technology or until we see NFC controllers able to support multiple of those. I guess we're actually hoping that everyone will just move to peer-to-peer or ndef exchange, because that removes this problem entirely. "Will developers be getting access to the secure element?" the presenters were then asked. "So this one kind of goes almost hand in hand with card emulation," Hamilton replied: Typically, the hardware is set up to do card emulation through the secure element. Right now, we don't have any APIs to talk to the secure element. And we think that we probably won't be getting APIs to do that anytime in the near future in the SDK. There are a bunch of different reasons. Again, the secure element is a very limited resource. It can't hold a large amount of data in there. And if we open it up to any third-party application, there's going to be a huge resource contention over the secure element. Additionally, to talk to the secure elements, even from applications on the phone, you need to authenticate yourself properly. And if you improperly authenticate yourself a certain number of times, there are secure elements out there that will physically destroy themselves and can never be recovered. So that's something that we really think would be a bad experience for users, and we don't want developers getting blamed for, you know, breaking hardware. It would be tough to know which application did it. We think it would be a very bad situation. So today, you know, we don't have APIs for that. And there are some constraints that make it tough to create APIs in the SDK for any third-party application to talk to the secure element. A follow-on question then asked if Google is aware of any vendors building payment solutions based on peer-to-peer mode. "I really hope so," Pelly replied. "I'd love to see peer-to-peer used for payment. I think ndef and peer-to-peer are the way to go going forward." "But are you aware of anything that's already in the works?," he was asked. "No," he replied. A video of the hour-long 'How to NFC' session is available on YouTube: During the presentation, the Google team also demonstrated a new addition to Android NFC functionality that is set to arrive with the forthcoming Ice Cream Sandwich version of the operating system. '0-click' ("zero click") will enable two devices to share and transfer information automatically without any user input beyond bringing two devices within close proximity of each other. A demonstration of 0-click can be seen starting at 0:13:57 in the video.Google raises concerns over the viability of NFC card emulation mode for mobile payments
