Near field communications (NFC)

From DAP WG Wiki

NFC is a low power very short range technology for communicating with unpowered tags, or between two powered devices such as NFC enabled smart phones. There is increasing interest in providing web page scripts with the means to interact with NFC devices. The starting point for this is to collect use cases as a basis for further discussion.

Note: this topic is part of FutureWork and a charter extension is likely to be needed before the Device APIs working group could proceed to publish Working Draft specification. Work on use cases is a valuable initial step towards that.

Some existing NFC APIs

Use cases submitted to DAP mailing list

Tran, Dzung D (发件人)

I have been working closely with the NFC group here at my company. Here are some use cases for thoughts:

  • Tap and Play: I can tap my device with another device and start playing a Peer-to-peer game.
  • Tap and Pay: I can tap my device with a commerce reader and pay
  • Tap and Share: I can tap and share a piece of data, like coupons, contacts.
  • Tap and Control: I can tap and control another device, like a TV remote
  • Tap and Read: Read NFC tags.

Bryan Sullivan

To add to the use cases already proposed by Tran, here are some more:

  • Bob checks into a hotel. The registration desk has an NFC terminal at which keys to access Bob's room can be transferred to his phone. Bob has a "My Keys" Webapp which manages his NFC keys. Bob uses his Webapp to collect his keys from the NFC terminal, through the NFC hardware on his phone. Later, Bob uses the "My Keys" Webapp to unlock his room door and open the minibar.
  • Mary's gym has NFC-enabled exercise equipment. Mary's phone has a "Just Did It" Webapp which tracks her workouts. Mary places her phone near the NFC terminal on various machines as she works out, and details on what she is doing are transferred to her phone automatically. After her workout, Mary touches the phone to her E-health monitor which has collected various info during her workout. The combination of the info in the "Just Did It" Webapp provides Mary a complete view of how effective her workout was.
  • Jan gets reward points for checking in at her favorite retailers. Having achieved the "queen of the realm" level for several retailers by faithfully checking in, she likes the fact that her checkin service is reliable and immune to false checkins. Her checkin service provider and retailers enable her to compete fairly on checkins by using NFC to ensure that she was actually in the store, and visited specific departments, as the NFC-based system gives them reliable data on her interests. Jan's "TapCheck" Webapp provides her an easy way to checking via NFC terminals, and to associate that data with ads, offers, and her social networks.

Dave Raggett

Some inspired by webinos:

  • Mary is visiting her friend Sophie and wants to use Sophie's wifi network. Mary taps her smart phone against Sophie's to instantly gain access without having to select the SSID and type the security password. This makes use of a peer to peer mode for data exchange, and assumes that Sophie has first launched an app to share her network credentials via NFC. An alternative would be for Sophie to write an NFC tag with her network credentials. The tag could have been provided with the DSL modem/wifi access point.
  • Webinos allows users to manage all of their personal devices as part of a strongly authenticated Personal Zone. NFC provides a convenient solution for enrolling new devices into your Personal Zone. Tap the new device against an already enrolled one (or against an unpowered tag). This configures the networking on the new device, and directs it to communicate with the Personal Zone Hub to initiate the enrolment process.

    This is an example of mutually authenticating two devices where you need to defend against man in the middle attacks. If the two devices share a secret key or know each other's public key, then this can be used to used to verify the authenticity of messages sent from one device to the other. The problem is how to safely share the secret or public keys in the first place. One way to address this is through out of band trusted channels. If both devices are in the same room both devices could display keys that the user then types into the other device. To avoid the pain and risk of errors when typing, the key could be rendered as a 2D bar code for scanning by the other device's camera. This approach is taken by J.M. McCune et al. in Seeing is believing. NFC peer to peer messaging would be even easier as you would just need to bring the two devices together after setting them into the mutual authentication mode. For webinos, the first step would be to install webinos on the new device. On starting this up, the device would then invite you to tap it against an already enrolled device. That device would be able to automatically initiate the enrollment service based upon the intent passed through NFC.

  • Valued added third party services for mobile payment -- for people to switch from their physical wallets to mobile wallets there needs to be a compelling benefit. Value added services around payments could be the key! In a proprietary solution, there are likely to be limited services, e.g. virtual coupons and loyalty card schemes. Open Web Standards would enable a much bigger pool of developers to create value added services. Some examples: Scan a given product to see if it is safe for you or your family to eat when you are concerned about specific allergies. If the product is unsafe, the app could suggest safe alternatives. Get further details on where a product was sourced and how it was produced. Keep track of the calories and nutritional value of the food you buy and perform month-end analyses that suggest improvements as well as recipes to go with the changes.
  • Phil needs to sign into his corporate intranet, and when requested taps his phone to his notebook computer as part of a secure authentication process. This makes use of NFC to communicate with a trusted computing module in the phone (the SIM card). One advantage of using a phone in this way over an NFC smart card is that it can provide its own UI, e.g. asking Phil to type in a PIN. Some corporate notebooks already include NFC support (e.g. my DELL Latitude E6500).

Under Android, the operating system figures out what application to handle a given tag. An example is the URL intent, which normally launches a browser for that URL. A web page launched in that way should be able to verify that the tag is present, e.g. by reading the tag.

NFC could permit multiple services for the same tap gesture, e.g. payment plus additional complementary value-added services. This would be based upon the ability for NFC tags to have multiple records, each serving a different purpose.

Payments and Wallets

NFC can also play an important role in payments. Here are some cases for consideration:

  • Tapping a phone against a point of sales terminal where the phone responds by launching the wallet to display the amount being requested and what it is for. The user can then be asked to choose the means of payment from those available in the wallet and to confirm the payment. Depending upon the amount involved, users may be asked to authenticate themselves, e.g. by typing a PIN or perhaps by swiping their finger on a finger print sensor on their phone. The phone is then tapped once more against the point of sales terminal to make the transaction.
  • Person to person payments where one person launches her wallet to indicate the amount to be transferred, and then taps her phone against the other person's. If the initiator is giving money to the other person, the recipient may asked to choose into which account the money is to be paid into. If the initiator is requesting payment then the situation is essentially the same as the previous use case.
  • Using your phone to pay when you are in an Internet cafe and browsing the web on a public computer. In this case the Web application invokes an API to request the payment, and the computer then acts as a point of sales terminal. The rest is as above.

In all three cases, one device initiates a request for payment (or refund), and another device provides the means to make the payment. Offline payments could be implemented in terms of signed electronic cheques that can be cleared when you are next online. For small amounts, applets in the secure element in each device could be trusted to transfer the amount by debiting and crediting the balances in each device respectively. A log of transactions could be kept as an audit trail, where each transaction is signed by both parties.

The wallet could be embedded within a device like a phone, or it could reside within the cloud. Likewise for payment solutions, which might rely on an embedded secure element or use a secure connection to the cloud. One design choice is whether the first device communicates directly with applets on the secure element on the second device, or instead communicates with a app/service on the second device, that in turn accesses the secure element. The latter is required when users are required to interact in some way with the second device, e.g. to confirm the payment and authenticate themselves. Note that wallets and payment solutions can be implemented as trusted web applications that are executed in a security context that isolates them from other applications. The browser or web run-time acts as a broker between the web application and the wallet, thus there is a need for a means for users to configure the browser to register their wallet.

Sylvain Lalande

Here are some more NFC use cases:

Tap and Pay : Mary is visiting an outlet and buys some items. As she arrives at the counter, Mary chooses to pay with credit card, takes out her mobile phone and taps on the payment terminal with her phone. A screen show up on the phone asking her to confirm payment and enter PIN code. Once entered, Mary taps again to confirm the transaction.

Tap and Travel, first example : John is on his way to the airport, in a taxi. En route, he connects to an airline site, and books a flight to London. Since the flight is within the next 2 hours, check-in is done automatically and an NFC boarding pass is directly sent to his phone. Using his favorite airline webapp, John can check his seat. At the airport, John board the plane directly by tapping his phone at the boarding gate.

Tap and travel, second example : John is in London. He downloads the Transport For London application to buy a weekly transport pass. John then uses his phone to enter and exit the public transport. At the end of the week, as the pass is about to expire, when John uses his phone to enter the underground, the TFL web app prompts John to buy another ticket.

Chengyan Zhang (张成岩)

Based on the ongoing discuss and the NFC terminal technical specification of my company, my suggestions for the current collection NFC user cases are as follows:

1, In order to ensure complete coverage of the needs of users as much as possible, I suggest that we should determine the operating modes at first, then we can further improve the user cases In the different modes. In my opinion, there are three main operating modes: Card emulation mode, that means the terminal can be simulated as an ordinary non-contact card; Reader mode, that means the terminal can read the other NFC tags as a reader; Peer to peer mode，that means the terminal can communicate with another NFC devices in point-to-point mode. Here are some examples in the different modes for reference as below:

  • Card emulation mode

E-key (as Bryan Sullivan has mentioned), E-ticket (Bob wants to see a movie. Then he goes to the cinema. The ticket office of the cinema has an NFC terminal at which customers can pay for the tickets and the tickets can be transferred to customers’ phones. Bob has a “My E-tickets” Webapp which buys and manages his tickets. Then Bob use this Webapp to buy the ticket and collect the ticket from the NFC terminal. Later, Bob uses “My E-tickets” Webapp to enter the cinema and watch the movie.) mobile payment (as Dave Raggett, Tran, Dzung D have mentioned)

  • Reader mode

E-posters (Bob is shopping in a big supermarket. Then he found a poster about the new movies which has a NFC tag. Bob has a “My tag Reader” Webapp which deal with the NFC tags. Bob used this Webapp to read the NFC tag and got a link，then the Webapp visited the link and shows more information about the new movie such as Synopsis, fare and so on.) information collection(as Bryan Sullivan, Dave Raggett, Tran, Dzung D have mentioned)

  • Peer to peer mode

data exchange (as Dave Raggett, Tran, Dzung D have mentioned), business card exchange( Bob participated in the W3C DAP meeting. Bob discussed a question with Tom. At last Bob and Tom decided to continue the discussion after the meeting. Then Bob and Tom wanted to exchange their business cards. Bob and Tom both had the Webapp named “business cards exchange” and saved their business card in their Webapps. Then Bob taped his smart phone against Tom's to instantly gain Tom’s business card, at the same time , Tom got Bob’s.) peer-to-peer control (as Dave Raggett, Tran, Dzung D have mentioned) peer-to-peer game (as Tran, Dzung D has mentioned)

2, Besides these normal NFC user cases, I suggest that we should consider the special user cases. Here are some examples for reference as below:

  • The operating modes should be changed automatically. e.g. Bob and Tom meet in the theater. Tom gave Bob a ticket by peer-to-peer mode. Then Bob used the ticket by the Card emulation mode.
  • services concurrency. e.g. Bob is on the Phone by using a headset; At the same time, he is using the Webapp to buy a ticket and collect the ticket from the NFC terminal.

I believe that there are many other special user cases that I do not mention, so I hope you could add more. Thanks a lot.

Jonathan Jeon (전종홍)

Retrieved from "https://www.w3.org/2009/dap/wiki/index.php?title=Near_field_communications_(NFC)&oldid=760"