W3C home > Mailing lists > Public > public-nfc@w3.org > August 2013

Re: documenting use cases

From: Luc Yriarte <luc.yriarte@intel.com>
Date: Thu, 01 Aug 2013 16:07:17 +0200
Message-ID: <51FA6B95.4020104@intel.com>
To: public-nfc@w3.org
CC: "Pourtier, Rene" <rene.pourtier@intel.com>, "Paut, Frederic" <frederic.paut@intel.com>
Hi all

I updated the draft to add just the use cases that involve reading / 
writing NDEF messages on a NFC tag, SNEP with NFC peer, and handover.
For these use cases, I also added a link to the relevant part of the 
API: NFCPeer, NFCTag, NDEF message.

> * Tap to Play: tap your device to another to play a peer-to-peer game
> * Tap to Share: tap to share some data, e.g. coupons, contacts.
> * Tap to Control: tap to control another device, like a TV remote
> * Tap to Connect: tap to connect via WiFi or Bluetooth
> * Tap to Read: tap to read NFC tags
> * Tap to Write: tap to write NFC tags

I left out the following use cases, as they may require card emulation 
or APDU / Secure Elements

> * Tap to Pay: tap your device to a sales terminal to pay
> * Tap to Request Payment: for person to person payments
> * Tap to Unlock: tap to open the door of your hotel room
> * Tap to Present Ticket: at a theatre, or on a bus or metro


> Some of the above use cases may require card emulation, e.g. tap to
> unlock, where a phone is being used in place of a contactless card.
> However, I am not sure of that, as I suspect that the peer to peer mode
> could be used instead, provided the device acting as the door lock is
> implemented appropriately. We need to be clear on this.

Probably "Tap to Unlock" and "Tap to Present Ticket" can be implemented 
with SNEP / peer to peer instead of card emulation, although I guess 
these use cases assume card emulation support - the hotel room door or 
the theater gate expect a NFC tag, and the device should emulate it.

> Likewise, some use cases may involve APDU access to secure elements,
> either on a contactless smart card or perhaps on the phone's SIM. The
> SysApps work item on an API for APDU access is expected to start fairly
> soon. It is an open question of how this will be used with NFC. One
> possibility is being able to use the NFC API to power the NFC hardware
> and initiate polling, and then to use the SysApps secure element API for
> APDU access to an NFC card or device. However, it may be easier to make
> the use of NFC transparent via a means for apps to register for events
> signalling when secure elements are connected (or brought within range

Right. I would say the API that defines events signalling a secure 
element should be the Secure Elements API, even if these events are 
triggered by the NFC stack when the NFC hardware is activated via the 

> of the NFC hardware). I suggest we explicitly state in the NFC working
> draft that we are not covering APDU access over NFC in the current draft.

In fact I believe we should add these SE/APDU related use cases once we 
can link to a S.E. API draft, and describe the interaction in the use 
case definition, something like "tap to pay: register a secure element 
event handler, then power on NFC hardware and start polling..."
But yes, in the meantime we should state explicitly that APDU over NFC 
is not covered, with some links to the S.E. works in the Sysapps group 
perhaps ?

> In some cases, we could have two apps communicating via NFC peer to peer
> messaging, where one of the apps locally uses APDU access to a device
> resident secure element. This could be the case for payments where a
> payment app needs to interact with the user, e.g. to show the amount
> being requested, and for asking the user to type a PIN or swipe her
> finger on a fingerprint reader. The current draft is fine for such cases
> since the NFC and secure element APIs are independent. Note that W3C
> expects to charter new work on user authentication via PIN or
> fingerprint swipe, however the details are still to be settled.

Many thanks for the use cases overview and all the input, Dave. I'll be 
in vacation from today on, back August 20th. Hope we'll make good 
progress then.



OOTO until August 20th.
For urgent issues, get in touch with René <rene.pourtier@intel.com>, my 
manager. Also see with Frédéric <frederic.paut@intel.com> for anything 
related to Cloudeebus.
Received on Thursday, 1 August 2013 14:08:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:43:36 UTC