W3C home > Mailing lists > Public > public-council@w3.org > March 2015

Web NFC Community Group Launched

From: <public-council@w3.org>
Date: Thu, 12 Mar 2015 12:07:31 +0000
To: "Wayne Carr" <wayne.carr@linux.intel.com>,"Jeffrey Yasskin" <jyasskin@google.com>,"Zoltan Kis" <zoltan.kis@intel.com>,"Aswini S" <ashumeow@live.com>,"Anssi Kostiainen" <anssi.kostiainen@intel.com>,Cc: public-council@w3.org
Message-Id: <E1YW1tj-0001b6-DS@maia.w3.org>
With your support, the Web NFC Community Group has been launched:

To join:

This group was originally proposed on 2015-03-11
by Wayne Carr. The following people supported its
      Wayne Carr
      Jeffrey Yasskin
      Zoltan Kis
      Aswini S
      Anssi Kostiainen
 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
 Optionally, initiation of NFC Card emulation mode for NFC devices, to
allow the use of a device for payments or for unlocking electronic door
 Optionally, initiation of handover mode to Bluetooth or WiFi
 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
 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

 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. 

Thank you,

W3C Community Development Team
Received on Thursday, 12 March 2015 12:07:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:16:38 UTC