Further background on NFC

From W3C Wiki

This page is intended to describe the potential for using NFC in Web applications along with what kinds of Web standards are needed to realize this potential.

Introduction

NFC is a form of short range wireless communication in which NFC devices can communicate with each other over a typical distance of 4cm or less. NFC cards or tags lack batteries and are instead powered by a radio frequency induction field generated by the NFC controller. NFC allows for two way communication. The NFC Forum defines standards for how cards and tags are formatted and the protocols for communicating with them. There are three modes:

  • read/write mode - the NFC device can read or write records, each of which has a type. There are currently 4 defined record types (Text, URI, Smart Poster, and Generic Control). Records can be set to read-only, and protected through encryption and digital signatures.
  • peer to peer mode - where two NFC devices exchange data, for example, data for setting up WiFi access, or data representing a business card.
  • card emulation mode - where a device acts in the same way as an NFC card, e.g. enabling an NFC enabled phone to be used for contactless ticketing and payment applications.

NFC cards have limited storage capabilities, e.g. the MiFare Classic 1K with 1024 bytes of data storage split across 16 sectors.

The main benefit of NFC is their speed and simplicity of operation for end users. Touch a card to a reader to pay for ride on the metro, touch an NFC phone to a tag on a poster to view the website for the associated event. Touch two phones together to exchange business cards.

In some cases no set up is needed as the card's record type is recognized by the NFC device's operating system, which automatically launches the appropriate application, such as the web browser. In other cases, as in peer to peer mode, the device will first need to run the corresponding application, and may involve asking the user to select what information to share.

Secure NFC Use Cases

What use cases are there for Web applications to make use of the security mechanisms exposed by some NFC devices?

Other Use Cases

Note that the charter of the Device APIs Working Group currently precludes that group from working on NFC.

Questions

The browser safe API sketch raises a few questions we would very much like to get your feedback on. Is it timely for work on Web APIs for using secure elements in conjunction with NFC? It would be really valuable to get some use cases involving NFC and access to secure computing/storage elements.

Is there sufficient demand for a separate W3C working group on NFC? If so, should it handle work on both browser level and system level NFC Web APIs, or should the latter be the responsibility of the proposed Systems Level Web APIs working group?

How to get involved

Please subscribe to the public mailing list public-nfc@w3.org. See the link on that page for details. If you have a W3C Account, you will be able to edit this wiki. To get a W3C account, fill out the account request form.

In case of further questions, please contact:

  • Dave Raggett <dsr@w3.org>

Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the W3C Patent Policy.

What is needed for using NFC with Web applications?

Subject to user consent, a Web application could make use of all three modes described above.

  • Imagine you are in a shopping mall, and tap a tag on a product with your smart phone. The operating system would launch the web browser on the URL provided by the tag, and the Web page could then read the tag to check that it is physically present, and to access additional information stored in other records, e.g. discounts for other products. This just requires a means to read the NDEF formatted records on the tag. A related use case is where you are visiting a friend's home and after launching your photo website, tap your phone to his television set to set up access to his WiFi network, and show your photos from last night's party on the large television display. The television set acts as a tag, and the application on your phone recognizes records containing the WiFi set up data, and the URL for the television set's service description.
  • In another example, the Web application could enable you to pass information to a friend by tapping your devices together. This would need a means to set the NFC device into the peer to peer mode. One use case would for multi-user Web-based games, where you start the application on your device and tap your friend's device to invite her into the game. Another example is inviting someone into a Web-based discussion room for commenting on some event you are both present at.
  • The card emulation mode can be used for payments and ticketing, but why would you need this mode from a Web page given the availability of the peer to peer mode?

Browser-safe NFC Web APIs

The act of the user tapping an NFC tag can be considered as consenting to allow the current Web application to read that tag. We just need some kind of call-back or DOM event listener to act upon the tap event along with access to data records read from the card. For writing to a tag, explicit user permission would be obtained, either when the Web application is first run, or the first time a tag is tapped using the application. If the user wasn't asked, an application could silently overwrite tags, e.g. with URIs that take you to an advertising site, which is probably not what the user expects.

Does putting the device into a peer to peer push mode require explicit user permission? The exact user experience would depend upon what information is being shared, and this may require the user to explicitly select that information as a means to check that the user wants to share what may be personal information. In that case separately asking for permission to push the information would be seen as a nuisance. Ideally, the user with the device that is tapped wouldn't have to do anything at all except perhaps for indicating consent to the operation being activated.

Suggestions for browser-safe NFC Web APIs?

Here is an initial sketch to set the ball rolling for discussions:

An event occurs when you tap your device on an NDEF formatted NFC tag (or the tag to your device). To set a call back for this event: 

 NFC.onndefdiscovered = function(event) {
     // event.records is an array of NDEF record objects
     // event.connection proxies the connection to a given tag or device
   }

The connection object as an event property allows for there to be multiple NFC controllers on the same device, and more importantly, for a given controller to scan multiple tags at the same time, and be able to write back to specific tag. The records property would be null if the tag requires formatting.

An alternative approach to setting a call back is to register a DOM event handler, e.g. 

 window.addEventListener("nfcdiscovered", function(event) {
     // do something useful here
   }, true);

Note that the discovery event is sent even if the operating system has just launched the Web application after discovering a tag with a URI intent (i.e. following the page load event). This allows applications to access all the records on a tag, which could be useful for determining the application's behavior. There is no need to tap the tag a second time, unless the app wants to write to it.

If we want to allow for more than just NDEF formatted tags, we could specify different discovery events for different tag types. Alternatively, we could add an NFC tag type property to the generic NFC discovery event nfcdiscovered. where the tag type is defined as a set of constants on the NFC interface, e.g. 

 NFC.TECH_OTHERS
 NFC.TECH_NFCA
 ...
 NFC.TECH_NDEF

There would be other discovery event properties, e.g. indicating whether the tag is writable, and the capacity of the tag.

How would the event signify that a tag is unformatted? One possibility would be for the event.records property to be null.

The NDEF record objects would have the following properties: 

 tnf    an integer indicating the nature of the record type property
 type   a string designating the record type as a URI, or a MIME type, or ...
 data   an ArrayBuffer containing the record's data
 id     an optional string value in the form of a relative or absolute URI

The tnf property would have values such as: 

 NFC.MIME_TYPE
 NFC.URI_TYPE
 ...

To write an NFC tag, you need to pass an array of records to the write method on the NFC interface: 

 NFC.ndefWrite(records, successCB, failureCB);

This would only work if there is an active connection to the tag. You would thus call this method from your handler for the discovery event. The arguments for success and failure call backs would be optional and need specifying. If we allow for multiple tags or controllers, the write method would be on the connection object (see above). The success call back wouldn't need any arguments. Likewise for the failure call back assuming that the error condition is accessible on the connection object or the NFC interface as appropriate. Alternatively an error condition could be passed as an argument to the failure call back.

Do we need to provide a property to check if there is an active connection with a tag? That seems redundant, as a connection would normally be active when the discovery event is handled. A failure call back on the write method would allow Web applications to deal with a loss of connection as well as other error conditions.

If the tag is unformatted, do we need to ask the user, or can the write operation silently format the tag before writing to it?

For peer to peer mode, we need a means to pass the records to be pushed. The receiving device gets an NFC discovered event as described above. The sending device calls the push method on the NFC interface: 

 NFC.ndefPush(records, successCB, failureCB);

The Web application can then invite the user to touch his device to his friend's device to perform the transfer. The arguments for success and failure call backs would be optional and need specifying. If there are multiple NFC controllers, is there a need to specify which one to use for a given push operation?

Finally, there could be methods on the NFC interface to allow the Web application to ask for the user's permission in advance to write to tags, or to push data. These would improve the user experience since the user wouldn't have to tap twice (otherwise, the first tap results in the permission dialog, and a second is required to complete the action). Is there a need to show users what data would be written or pushed, and if so how would that work in practice?

Remember that the above is just a sketch and intended to stimulate questions and help us to reach a consensus as we develop a common API starting from the various existing proposals.

Logical Link Control Protocol (LLCP)

LLCP supports peer to peer communication between NFC devices with connectionless and connection-oriented services. The NFC Forum suggests that applications could make use of TCP/IP on top of LLCP, e.g. for transferring small files, or even for an HTTP server, Web Sockets connection or HTML5 Message Channel. LLCP is relatively new, and as such, not as widely deployed as NDEF.

A simple approach for peer to peer asynchronous messaging between LLCP devices could look like: 

NFC.peer(successCB, failureCB);

The success call back is passed a newly created MessageChannel object. The app can now set a listener on port1 and send messages to port2. If the peered device is running a web application, it would get a DOM event to signal the establishment of the peer to peer connection along with the corresponding MessageChannel. See HTML MessageChannel.

Card Emulation Mode

Some controllers can be put into a mode where they appear as a NFC card/tag to other NFC controllers. For NDEF, this would similar to the interface for NDEF push: 

NFC.ndefCardEmulation(records, successCB, failureCB);

However, we also need a means to restore the controller from the card emulation mode, e.g. 

NFC.ndefReset(successCB, failureCB);

An open question is where card emulation mode is capable of supporting APDU based smart cards, see next section.

APDU messages

What is needed to support the application protocol data unit (APDU) message format? This essentially involves the controller sending a command to the smart card, which then responds.

The structure of the APDU is defined by ISO/IEC 7816-4 Organization, security and commands for interchange, but a summary can be found on the Wikipedia page.

  • The command APDU consists of a 4 byte header, 0 to 255 bytes of data and a variable length field encoding the maximum number of response bytes expected.
  • The response APDU has a 2 byte header and a variable number of bytes of data depending on the operation invoked. There is also a 2 byte command processing status code.

An open question is how much knowledge to assume in the design of the corresponding Web API. In a minimal design, you would pass a byte array to the controller, and be called back with a status code and a byte array containing the response, e.g. 

NFC.ndefApduCommand(byte array, successCB, failureCB);

A knowledge intensive design would allow you to use separate methods for each smart card command. Some open questions include:

  • Do APDU based smart cards support discovery similar to NFC cards?
  • How do you determine the kind of smart card and the commands it supports?
  • Is the set of commands and responses sufficiently manageable to hard code in the web run-time?
  • Is there a notion of a communication session with the contactless smart card?
  • Is there interest in supporting contact-based smart cards?

Gemalto has provided a draft API definition for access to secure elements, which is based upon APDU messages.

In this API, we have been proposing to have the capability to manage APDU messages, together with event (e.g. a reader detecting the insertion of a new secure element, or a contactless card communicating with the browser). This is an idea we have been working on since few months now, and it is obviously open to discussion

ECMA Standards for NFC

NFC-SEC allows NFC devices to securely exchange a shared secret key for symmetric encryption of subsequent communications. The nature of the short range wireless communication for NFC makes man in the middle attacks very hard to implement.

Note: ISO/IEC published the ECMA 385,6 standards as ISO/IEC 13157-1 and -2 respectively.

Further information is available from ECMA TC47-M.

System-Level NFC Web APIs

These offer lower level access to NFC devices.

Some existing NFC APIs

Apart from the first two, these are all Web APIs exposed by the Web run-time to applications, and from an application developer perspective, it would be preferable if the various platforms all used the same system level NFC Web APIs.

Proposed APDU API

W3C Royalty-Free Licensing Requirements

A device supporting NFC may require the licensing of the NFC hardware, the protocol stack, and the API exposed by the operating system. However as far as is currently known, no licenses would be needed for implementing W3C NFC APIs exposed to web run-times on top of the operating system's native NFC API. As such there are no conflicts with W3C's RF licensing rules as define in the W3C PatentPolicy. This is directly analogous to implementing Web browsers on a device using a mobile connection for Internet access, where the mobile network is encumbered with patents requiring RAND licenses.

Note: See Rigo Wenning's analysis for the AC Forum.

Retrieved from "https://www.w3.org/wiki/index.php?title=Further_background_on_NFC&oldid=63053"