Re: Web NFC Community Group Proposed

Missing URL and a final missing paragraph. Here it is corrected.


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.

The Web NFC Community Group Charter can be found at 
http://w3c.github.io/nfc/charter/cg/index.html. The input specification 
can be found at http://w3c.github.io/nfc/. 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.


On 2015-03-11 13:50, Do Not Reply wrote:
> The Web NFC Community Group has been proposed:
>
> --------------------------------------------------
>
>   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.
>   The Web NFC Community Group Charter can be found at
> http://w3c.github.io/nfc/ .  The input specification can be found at   .
>   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
>
> --------------------------------------------------
>
> You are invited to support the creation of this group:
>    http://www.w3.org/community/groups/proposed#web-nfc
>
> Once the group has a total of five supporters, it will be launched and
> people can join to begin work. Once launched, the group will no longer
> be listed as "proposed"; it will appear in the list of current groups:
>    http://www.w3.org/community/groups/
>
> In order to support the group, you will need a W3C account. To request one:
>    http://www.w3.org/community/account/request
>
> 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
>
>
>