NFC working group face to face -- 14 Nov 2013

<scribe> scribe: Dave

<scribe> scribenick: dsr

we review the editor's draft http://www.w3.org/2012/nfc/web-api/

for the use cases, tap tp play to play a peer to peer game, we think this means to initiate a peer to peer game.

or perhaps it is better to add the peer to peer gaming as a use case for the tap to connect and handover, We would then drop the tap to play line.

Jinsong: what about tap to launch an app?

Dave: the operating system will handle that, e.g. smart poster (tag as URL) and operating system prompts and loads the browser on the URL.
... but what if we have a service worker? We could then handle requests and for example launch a locally installed app.

Jacques: that sounds like something for future discussion. (when service worker matures)

Dave: it might be worth giving slightly longer descriptions for each of the use cases.

We seem to have copied the list of use cases from those submitted by Tran, Dzung D (发件人) to the Device API's mailing list before the NFC WG was chartered,

We could ask Tran directly (via email) for more details, or we could come up with some ideas ourselves and ask for feedback on the NFC WG mailing list.

For tap to control, there are commercial TV remotes that use Bluetooth, and so we could imagine handing over to Bluetooth and using the Bluetooth API being developed by SysApps.

Dave notes that most remotes use infrared, and in future we could envisage a W3C API for controlling infrared.

For tap to connect, this could be just to get the credentials to connect to a WiFi network, but more interesting is to then launch a specific service, e.g. a promotional website for the store that you just entered.

A related example is a wireless charging station built into tables at a cafe. Placing your phone on the icon on the table charges the phone and launches the browser at the promotional website.

<aboyet> Tap to Read could potentially inspect the contents of parts container received on factory floor and automatically initiate the parts tracking system to update counts and locations and potentially kick of other activities/processes

Dave: I reckon we need to expand the introduction to clarify that you are expected to have launched a web app that takes over the NFC hardware, and show how the use cases fit into this context.

I think that service worker will be picked up by the WebApps WG. We should then make sure that the service worker spec can handle the NFC use cases.

Looking at example 1, is it explained in the text that follows?

Dave: I think we need a very brief explanation immediately after example 1.
... I think we need some normative references to the NFC Forum specifications for the things we depend upon.

We could ask the NFCForum for their advice on what normative references to make.

<jack> I'm taking action for adding more references on NFC Forum specs

Manu: you should have an acknowledgement section listing the working group members,

We can also think about informative references to external introductions to NFC and longer accounts of use cases, and primers for how to use the API.

Adam: how are errors dealt with?

Manu: for promises there are generally bail outs on errors

Jacques: we need to add some treatment of errors.

Dave: an example could be where powerOn or startPoll methods fail for some reason.
... we could include an example of catching an error (perhaps a .finally?)

Example 1 indeed shows how to do that, but needs some explanation.

We still need to enumerate just what the errors are and when they occur.

<jinsong> manu: combine nfc things with webpayment, webpayment apis, want people to go to website, and click without credit card info

<jinsong> ...select what you want to buy, put your phone on it, click by the nfc or else

<jinsong> ...want a wireless way to make it happen, not care of nfc or bluetooth

<jinsong> dsr: bluetooth low energe for beacon

<jinsong> ... recharter Geolocation, might some case to transfer info over bluetooth/wifi/nfc?

<manu1> manu: Here are a couple of links for the Web payments work:

<manu1> manu: Here's the introduction to the Web Payments work: https://payswarm.com/intro

<manu1> manu: Here's the instructions on how to join the Web Payments work: https://payswarm.com/join

<manu1> manu: here's the result of the Web Payments workshop: https://payswarm.com/minutes/2013-11-13-workshop/

<manu1> manu: here's the result fo the web payments workshop... minutes stored at W3C: http://lists.w3.org/Archives/Public/public-webpayments/2013Nov/0035.html

<manu1> manu: here are all of the specs we're working on right now: https://payswarm.com/specs/

<manu1> manu: Here are the use cases: https://payswarm.com/specs/source/use-cases/

<jinsong> manu: section 2.8 in use cases doc

<jinsong> ...section 2.10 automated vending

<jinsong> ... the 2 main use cases

<manu1> manu: Two main use cases are NFC-based payment where the payment is routed through a point of sale device, such as a kiosk.

<manu1> manu: The other use case is NFC-based payment where the payment is routed through a network-connected device, such as a mobile phone.

<manu1> manu: Some future use cases - Laura walks into a museum and only wants to pay for the exhibits that she goes to see. When she buys her general admission ticket to the museum (which costs very little), she authorizes the museum to pull funds from her as she walks into each section of the museum.

<manu1> manu: As she walks into a section, she can wave her phone over a checkin gate that will autocharge her on admission. She doesn't need to unlock the phone or interface with the UI since she already pre-authorized the museum to pull funds (up to a certain amount) from her.

<manu1> manu: NFC plays a part in this, so does the geolocation API, as well as Secure Element, Web Crypto etc.

<manu1> manu: Another one is payment for accessing a public transit system. The functionality is the same as above. Travis walks into a subway station, has previously paired his phone to the transit system, and every time they wave the device, a Web Payments request is initiated and processed. The key difference is the protocol for doing all of these purchases (at the museum, on public transit, at the

<manu1> grocery store) all use a standard open payment protocol running over NFC.

<manu1> manu: NFC can also be paired to a device with network connectivity. For example, a vending machine that has no network access could perform a web payment by routing the payment through the device that is making the payment (such as a mobile phone).

<manu1> manu: In this use case, Ben walks up to the vending machine, sees a drink that he wants to buy. He selects the drink and the kiosk asks for him to place his phone on the payment area of the kiosk. The product description is delivered over NFC, he authorizes the purchase, the purchase request goes to his payment processor over his mobile connection, a digital receipt is generated, digitally signed

<manu1> and returned to his phone. The phone then relays this digital receipt (used as a proof of purchase) via NFC back to the vending machine. This allows the vending machine to process payments over any other network in a secure manner (since the digital receipt is digitally signed and is thus very hard to spoof. The only thing the vending machine needs to implement is a mechanism to verify a digital

<manu1> signature (and a list of signing keys that it trusts).

Manu: if your browser has multiple tabs open and apps open on different tabs are calling NFC power on and power off, then there needs to be some way to only turn the power off when all the pages that powered on have powered off.
... bikeshedding, perhaps you should replaced the NDEF prefix by NFC to avoid the expectation that people reading the spec have previously read about NDEF and the NFCForum documentation.

Dave: we need to talk to the NFCForum about references and at the same time we should try to get a feeling for their expectations for future changes, e.g. new kinds of messages other than NDEF.

Manu: the interface types should fit into the broader set of W3C interfaces, so something identifying this as a NFC type would fit better.
... you may need to have both low level and high level interfaces for less sophisticated developers.

Dave: library developers like the flexibility of lower level interfaces, and it is better to define high level interfaces once common patterns of usage become clear (paving the cow paths)

The W3C NFC API can be used to interoperate with native apps, so it makes sense to use a shared vocabulary rather than defining a W3C specific one.

Manu: unclear what smart posters are - some explanation would help.

The wording for open needs changing (open for edition --> open for editing).

we resume after lunch

David: how does the W3C NFC API do when cards with secure elements are presented?

Jacques tries this out using an implementation of the API under PhoneGap. The card is picked up by Android and not by the app running the W3C API.

Dave: I was talking with Jinsong this morning and he mentioned that Chinese companies may have use cases and requirements that aren't satisfied by NDEF formatted tags.

David: the two booleans powered and polling could be abused and in any case my give rise to race conditions. It would be better to drop them.
... the promise on powerOn() and startPoll() likewise make the onpoweron, onpoweroff, onpollstart and onpollstop kind of redundant.

Dave: okay we could drop the two booleans and the 4 events, but we would need to clarify the errors and to provide the status info with the errors.

calling powerOn when power is already on should be safe and likewise for startPoll

David: what is the use case for powerOn without polling? If there isn't one you could make power on implicit with start polling.

Dave: with multiple apps running on the phone at the same time and independently calling start and stop polling, then the onstartpolling and onstoppolling would allow an app to recover when another app stopped polling and the first app wants polling.

However, an alternative is for the underlying NFC manager to use a counter and if N apps started polling to decrement the count on stop polling, and only actually apply that when the count is zero. Calling stop polling when the count is zero has no effect on the count.

Jacques: what if an app crashes?

Dave: we should treat that like process file and stream handles in Linux that are closed when a process ends.

Jacques: I think there is an error: the readNDEF method should return an NDEFMessage not an NDEFRecord with its promise.

David: are there any problems if you set the event handler after calling the method? That should work, but what if it doesn't (like the onload method for img)

We should be explicit about queuing events in this spec.

scribe: implementations must not drop events.

<dezell> img.src="http://somenewimage.jpg";

<dezell> img.onload=callbackForOnload();

David: this is deplorable and should be taken up with the HTML working group.

Dave: what does the red x mean in the tables in section 10.2?

We think it means "no".

http://www.w3.org/2012/nfc/web-api/

Our thanks to David Ezell for some excellent feedback.

We break for coffee and end the meeting.

- DRAFT -

NFC working group face to face

14 Nov 2013

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output