documenting use cases

On 26/07/13 17:56, Yriarte, Luc wrote:
> - Actions:
> - Dave sends a few links to existing specs including use cases, as examples
> - Luc updates the draft to include use cases.

One example is the SysApps telephony API:

   http://www.w3.org/TR/2013/WD-telephony-20130620/

which simply links to the SysApps wiki page on the telephony API. The 
use cases provided are currently very terse indeed.

The SysApps runtime spec:

   http://www.w3.org/TR/2013/WD-runtime-20130321/#use-cases

once again, very terse.

It doesn't seem like there are consistent practices for including use 
cases as part of specification documents. Some working groups put then 
into separate documents that are published as working group notes, e.g.

    http://www.w3.org/TR/2013/NOTE-webaudio-usecases-20130129/

So we have a choice between:

  a.  include terse descriptions of use cases in the NFC spec

  b.  put longer descriptions of use cases in a WG Note

My suggestion would be to do (a) and for Luc to use his judgement in 
collating and summarising the wording from the examples in

http://www.w3.org/2009/dap/wiki/Near_field_communications_%28NFC%29

We can always update the use cases as we publish updates to the working 
draft. If we have terse descriptions, they could be inserted in a new 
sub-section following the introduction, otherwise an appendix may be 
preferable.

A very rough first cut at a summary:

-----8< cut here-----

The current draft allows for reading and writing NDEF tags, for peer to 
peer exchange of NDEF messages, and for handover to WiFi or Bluetooth. 
Here are some possible use cases:

* Tap to Play: tap your device to another to play a peer-to-peer game
* Tap to Pay: tap your device to a sales terminal to pay
* Tap to Request Payment: for person to person payments
* 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 Unlock: tap to open the door of your hotel room
* Tap to Present Ticket: at a theatre, or on a bus or metro
* 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

Some of the use cases require you to prepare your device before you tap 
it against another. This could be opening your wallet application to 
request a payment, or browsing to select the data you want to transfer, 
or to write to an NFC tag. In other cases, we assume that there is a 
running system app that is listening for other devices, and which 
initiates a behaviour based upon the ensuing communication with the 
other device.

-----8< cut here-----

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.

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 
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 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.

Best regards,
-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Wednesday, 31 July 2013 14:52:10 UTC