Skip to toolbar

Community & Business Groups

Proposed Group: Web NFC Community Group

The Web NFC Community Group has been proposed by Wayne Carr:


The Web NFC Community Group will create a Near Field Communication API for use with the Web security model, so safe for use in Web Browsers. We believe that means that the API will not expose full, low level NFC functionality, but rather a higher level subset that is safe for Web pages, protects user privacy, and doesn’t annoy users with unnecessary or complex permission requests. See the Web NFC Community Group Charter and NFC input specification for more information. Anssi Kostiainen will be the initial Chair.

The scope of the Web Near Field Communications Community Group is limited to the development of APIs for Web page scripts to perform the following operations with NFC devices:

  • Reading NDEF messages;
  • Writing NDEF messages;
  • Setting NFC tags to read-only;
  • Peer to peer exchange of NDEF messages between NFC devices;
  • Optionally, manual connection for various technologies, e.g. NFC-A and NFC-F;
  • Optionally, initiation of NFC Card emulation mode for NFC devices, to allow the use of a device for payments or for unlocking electronic door locks;
  • Optionally, initiation of handover mode to Bluetooth or WiFi technology.

The APIs will be designed to permit execution in the Web browser context, using the security model of the Web. The very short range of NFC devices requires users to make a conscious decision to put one of the devices into the appropriate mode and to bring the devices physically together, and this should enable a simpler security model that minimizes the need for applications to ask for explicit user permission. The need for direct user involvement under circumstances will need to be explored.

The CG will explore permission models that take advantage of the physical properties of the NFC connection to align user expectations with the permissions actually granted to script. Aspects of the environment that might go into the permission model include:

  • Whether the script is running in the frontmost tab or window;
  • Whether the script is running in an open tab or window (vs. a Service Worker);
  • Whether the script has been vouched for by a trusted authority, such as applications installed from a store or shipped with a device;
  • The user’s interactions with permission and choice prompts;
  • Preferences expressed by the tag or peer NFC device itself;
  • Whether the application has been given additional trust by being “installed”, ie. added to the home screen.

The Community Group will also explore the possibility of sites registering with the user agent for particular types of messages. When multiple registrations are made for a particular type of message, a chooser is shown to the user to select among sites to handle the available message. Considerations like these could simplify user interactions for granting permissions while preserving privacy and security. The CG will explore permission systems that allows users to control in a clear and concise way the nature of NFC interaction between pages and NFC tags or devices. For instance, answering “yes” to a permission dialog for using NFC during a read use case must not enable NFC usage in general, and particularly must not enable a page to overwrite a writable tag in a way the user did not clearly expect. Nor can it mean that a web site can initiate a P2P communication with an NFC device which can have effects that the user did not intend. The Community Group may consider both an API for use by an untrusted web site, as well as an enhanced API available to a web site is considered trusted.

The CG will consider requiring that for riskier API’s, the user has agreed to allowing a potentially risky or experimental API for a particular trusted web site. The web site is known through use of HTTPS so some APIs could be restricted to use only by known, trusted web sites. The CG could also consider use of some APIs only for sites in the local network (if permitted by the user). For example, where a device in the local network offers a web page (using https), the user could grant that web page permissions beyond what normally is allowed for random web pages. That would allow for a set of APIs, one safe for any web site and then perhaps others that require higher levels of trust and permission.


You are invited to support the creation of this group. Once the group has a total of five supporters, it will be launched and people can join to begin work. In order to support the group, you will need a W3C account.

Once launched, the group will no longer be listed as “proposed”; it will be in the list of current groups.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please send us email on site-comments@w3.org

Thank you,
W3C Community Development Team

Leave a Reply

Your email address will not be published. Required fields are marked *

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.

*