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:
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 web site 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 Community 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.
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 Community Group is limited to the development of APIs for Web page scripts to perform the following operations with NFC devices:
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:
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.
The Community Group will be implemented on top of NFC implementations provided by the platform. Low level NFC specification is out of scope.
The CG will define a Web NFC API specification, suitable for use from Web Browsers. The CG may also create a specification related to permissions and security governing availability or use of APIs. This could include defining particular message content related to permissions and security. The CG is free to arrange these specifications into one or more specifications for convenience. However, all Specifications being worked on must be clearly indicated on the CG Web page. Example of what the specification could look like: http://w3c.github.io/web-nfc/.
The group MAY produce other Community Group Reports within the scope of this charter but that are not Specifications covered by the CLA, for instance use cases, permission ceremonies, security hardening reports, etc.
At present, there are no plans to create a test suite. If, however, the CG decides to develop a test suite, it will be developed in Open Source using the W3C Software License.
This 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.
Terms of in this charter that conflict with those of the Community and Business Group Process are void.
The group will not publish Community Group Reports that are Specifications other than those described in "Community Group Reports that are Specifications" above. See below for how to modify the charter.
Contributions can only be made by Community Group Participants (so all Contributors have agreed to the CLA). Particular care must be taken to ensure Contributions of content that is implementable comes from Community Group participants.
Community Group Participants agree that all Contributions will be documented in pull requests and commits for a particular document in the group's GitHub repository.
For Contributions to Specifications, if someone other than the Contributor makes the pull request, the pull request SHOULD indicate who the request was made on behalf of and SHOULD provide a reference to the relevant archived GitHub Issue or group mail thread where practical. The information SHOULD be specific enough to easily determine who the Contributors were and that the intention was to change a particular Specification. In the commit, if practical, this information SHOULD be in the form {Contributors: ["githubusername1","githubusername2"]}.
For software, the GitHub Contributing and License files describes how to Contribute and the license under which Contributions are made.
This group will seek to make decisions when there is consensus. When the group discusses an issue on the mailing or Issues list and there is a call from the group for assessing consensus, after due consideration of different opinions, the Chair should record a decision and any objections.
A common way to determine consensus for important decisions is to conduct a Call for Consensus (CfC) where the Chair puts a proposal to the group on the public mail list and asks for feedback from the Participants within some period of time that is at least 7 days. Not responding indicates going along with the proposal. Direct feedback is encouraged, especially to weigh the degree of consensus when there is dissent.
Participants MAY call for an online vote if they feel the Chair has not accurately determined the consensus of the group or if the Chair refuses to assess consensus. This should be a rare event, only where the usual, less formal means of making decisions are not accepted. At least 5 Participants, no two from the same organization (or 50% of the organizations and individuals, whichever is smaller), MUST agree with the call for a formal vote. The call for a vote MUST specify the duration of the vote which MUST be at least 7 days and should be no more than 14 days. The Chair MUST start the vote within 7 days of the request, or group members MAY start it themselves. The decision will be based on the majority of the ballots cast. It is the Chair's responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favor or discriminate against any group participant or their employer.
The group will conduct all of its technical work in public.
Discussions MAY take place on the group's public mailing list. Other discussions MAY take place using Issues in the group's GitHub repository. For convenience, GitHub issues and pull requests will be archived to the group's contrib list. Other contributions MAY be directly posted to the contrib list.
Meetings MAY be restricted to Community Group participants, but a public summary or minutes MUST be posted to the group's public mail list.
Any decisions reached at any meeting are tentative. Any group participant may object to a decision reached at a meeting within 7 days of publication of the decision on the mail list. That decision must then be confirmed on the mail list by the Decision Process above.
Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer.
The following process is used if the less formal process above is not acceptable to group members. If 5 participants, no two from the same organization, (or 50% of the organizations and individuals, whichever is smaller) call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777). Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes. Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes —no two from the same organization— is elected chair. In case of a tie, RFC2777 is used to break the tie. An elected Chair may appoint co-Chairs. Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
The group MAY decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.