[DRAFT] Web Near Field Communications (NFC) Working Group Charter
The mission of the Web Near Field Communications Working Group is to develop a standard API for Web applications and Web pages to access NFC devices.
| End date | 1 March 2017 |
|---|---|
| Confidentiality | Proceedings are Public |
| Initial Chair | Jacques Bourhis |
| Team Contact (FTE %: 10) |
Kazuyuki Ashimura |
| Usual Meeting Schedule | Teleconferences: topic-specific calls may be held.
Face-to-face: we will meet during the W3C's annual Technical
Plenary week; other additional F2F meetings may be scheduled (up to
2 per year) IRC: active participants, particularly editors, regularly use the #nfc W3C IRC channel |
Background
Near-field communication (NFC) is a form of short range wireless communication in which NFC devices such as mobile phones can communicate with each other over a typical distance of 4cm or less. NFC allows for two way communication. The NFC Forum defines base standards for how smart cards are emulated by NFC devices and NFC Forum tags are formatted and the protocols for communicating between devices. There are three modes of operation:
- read/write mode - the NFC device can read or write records, each of which has a type. There are currently several defined record types (Text, URI, Smart Poster, etc.). 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 an NFC device emulates a smart card, e.g. allowing an NFC enabled phone to be used for contactless ticketing and payment applications. Emulated cards may 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 the 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 NFC 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, which may involve asking the user to select what information to share.
The Web Near Field Communication Working Group will define an API for Web page scripts to use the NFC data exchange format and APDUs, enabling a range of use cases for reading, writing, emulating cards and data exchange with peer NFC devices. Further background information can be found on the NFC Wiki.
Scope
The goal is to provide a Web NFC API that satisfies the most important use cases for NFC from Web pages. 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 scope of the Web Near Field Communications Working 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 Working Group will explore permission models that recognize the special role of the frontmost, foreground tab when NFC devices are brought into close proximity by the user. The Working 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. However, answering “yes” to a security question must not enable a page to overwrite a writable tag in a way the user did not expect. Nor can it mean that a website can initiate a P2P communication with an NFC device which can have effects that the user did not intend. The Working Group may consider both an API for use by an untrusted website, as well as an enhanced API available to a Website is considered trusted.
The WG will consider requiring that User Agents implement the Web NFC API to be HTTPS-only. The WG will consider requiring that for riskier API's that the User Agent knows which user is logged into the User Agent and knows what types of permissions that user is allowed to set, and the user has agreed to allowing a risky or experimental API for a particular trusted website. The identity of the user would be known by the User Agent (but not the web page), to know what is permitted for use by that Web site. The Web site is known through use of HTTPS so some APIs could be restricted to use by particular users and only by known, trusted websites. The Working Group 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 website and then perhaps others that require higher levels of trust and permission.
Out of Scope
The Working Group will not define underlying protocols or low level access APIs, but rather a Web API that provides a suitable abstraction for Web pages, with implementations using the underlying platform for NFC functionality.
Success Criteria
To advance to Proposed Recommendation, each specification is expected to have two independent implementations of all features defined in the specification
Deliverables
The Working Group will develop specifications for one or more W3C Recommendations covering the scoped functionality.
Milestones
| Note: The group will document significant changes from this initial schedule on the group home page. | |||||
| Specification | FPWD | CR | PR | Rec | |
|---|---|---|---|---|---|
| Web NFC API | Q2 2015 | Q1 2016 | Q2 2016 | Q1 2017 | |
Dependencies and Liaisons
This Working Group’s specifications have no direct dependencies on any other developing specification other than the Web Applications Working Group’s Web IDL specification, which many W3C specs depend upon. However, several other groups would provide valuable feedback and they will be asked to review drafts.
W3C Groups
This Working Group expects to ask the following W3C Working Groups for reviews of deliverables, and where appropriate to liaise on potential synergies:
- Device APIs Working Group
- The NFC Working Group will coordinate with the Device APIs Working Group to ensure that the NFC API can be used effectively together with Web Intents.
- HTML Working Group
- The NFC Working Group will coordinate with the HTML Working Group to ensure that the NFC APIs conform to the privacy and security model for Web browsers.
- Web Security Interest Group
- The Web Security Interest Group should be asked to review deliverables to secure reviews on its deliverables from the Web Security Interest Group to ensure they offer the right level of security.
- Privacy Interest Group
- The Privacy Interest Group should be asked to review deliverables for privacy considerations.
- Web Cryptography Working Group
- Interaction with this group would be valuable for the potential synergies between work on JavaScript cryptographic APIs and access to secure elements on NFC devices.
- Web Bluetooth Community Group
- The Web Bluetooth Community Group should be asked to review deliverables to take advantage of their general expertise in exposing wireless technologies for Web standards. The NFC WG will closely follow the work of the Web Bluetooth CG, exploring the similarities of the approach on using these technologies by Web pages.
- Trust and Permissions Community Group
- The Trust and Permission Community Group may explore the notion of trusted websites, which would allow use of enhanced APIs that are available for use only in trusted pages.
- WAI Protocols and Formats Working Group
- The WAI Protocols and Formats Working Group should be asked to review deliverables in order to ensure the API supports accessibility requirements, particularly with regard to interoperability with assistive technologies, and inclusion in the deliverable of guidance for implementing the group’s deliverables in ways that support accessibility requirements.
- Internationalization Activity
- The Working Group will ask for reviews to ensure any I18N issues in the API are addressed.
External Groups
- NFC Forum
- The NFC Working Group will liaise with the NFC Forum to ensure that the W3C NFC API is compatible with the NDEF specifications defined by the NFC Forum.
- ISO and ECMA
- The NFC Working Group will build upon the capabilities provided by NFC related standards developed by ISO/IEC/JTC 1 SC 6 and SC 17, and by Ecma International.
Participation
To be successful, the Web Near Field Communications Working Group is expected to have 8 or more active participants for its duration, with at least one major Web Browser implementer.
If an extended period of time passes without two (2) independent implementers in the Working Group, the Working Group will move the unfinished specification to a Community Group.
Effective participation in the Working Group is expected to consume one work day per week for each participant; and up to two days per week for editors. The Web Near Field Communications Working Group will allocate also the necessary resources for building Test Suites for each specification.
The Working Group welcomes participation from representatives of W3C Member organizations. To enable a broad spectrum of input, the group also anticipates the active participation of individuals as W3C Invited Experts (read the policy for approval of Invited Experts). Participation from W3C Members and non-Members alike will help ensure the goals of this charter are effectively addressed. Invited Experts in this group are not granted access to Member-only information.
Participants are reminded of the Good Standing requirements of the W3C Process.
Communication
This group primarily conducts its work on the public mailing list public-nfc@w3.org (archive). Administrative tasks may be conducted in Member-only communications.
Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Near Field Communications Working Group home page.
Decision Policy
As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation—using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.
Asynchronous decisions that are attained through the mailing list, possibly using a “Call for Consensus” process are preferred, but synchronous decisions made during a teleconference or a face-to-face meeting are valid provided that the topic they address was clearly outlined in a public agenda posted one week earlier so that non-participating parties have a chance to voice their views ahead of time.
This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.
Patent Policy
This Working Group operates under the W3C Patent Policy (1 August 2014 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.
For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
If this WG decides to halt work on any specification that has been published as a FPWD but has not reached REC, or if the WG disbands with a specification in that state, the unfinished specification will be published as a WG Note under a copyright license that allows for adoption and continuation of work on the specification by a W3C Community Group.
About this Charter
This charter for the Near Field Communications Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
This charter should only be approved if at least one major Web Browser implementer indicates in the AC review that they want to join the WG and would implement if the spec was appropriate.
Please also see the previous charter for this group.
Kazuyuki Ashimura <ashimura@w3.org>, W3C Staff ContactCopyright©2015 W3C ® ( MIT, ERCIM, Keio, Beihang), All Rights Reserved.
$Date: 2015-01-31 19:28:16 $