Abstract

Near Field Communication (NFC) enables wireless communication between two devices at close proximity, usually less than a few centimeters. NFC is an international standard (ISO/IEC 18092) defining an interface and protocol for simple wireless interconnection of closely coupled devices operating at 13.56 MHz (see https://www.nfc-forum.org/specs/spec_list/).

This document defines an API to enable selected use-cases based on NFC technology.

Status of This Document

This specification was published by the Web NFC Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

Implementers need to be aware that this specification is considered unstable. Implementers who are not taking part in the discussions will find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation phase should subscribe to the repository on GitHub and take part in the discussions.

Significant changes to this document since last publication are documented in the Changes section.

If you wish to make comments regarding this document, please send them to public-web-nfc@w3.org (subscribe, archives).

Table of Contents

1. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119].

This document defines conformance criteria that apply to a single product: the UA that implements the interfaces it contains.

Implementations that use ECMAScript to implement the APIs defined in this document MUST implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL], as this document uses that specification and terminology.

2. Terminology and conventions

The term browsing context refers to the environment in which Document objects are presented to the user. A given browsing context has a single origin and a single WindowProxy object, but it can have many Document objects, with their associated Window objects. The browsing context identifies the entity which invokes this API, which can be a web app, a web page, or an iframe.

Inspired by the Streams specification, we use the notation x@[[y]] to refer to internal slots of an object, instead of saying "the [[y]] internal slot of x."

The Augmented Backus-Naur Form (ABNF) notation used is specified in RFC5234. [ABNF]

The term script execution environment is defined in [HTML5].

The term top-level browsing context is defined in [HTML5].

The term incumbent settings object is defined in [HTML5].

The term secure context is defined in [WEBAPPSEC].

The term of executing algorithms in parallel is defined in [HTML5].

URL is defined in [URL].

The term document base URL is defined in [HTML5].

The term URL path is defined in [URL].

The term origin is defined in [HTML5].

The term ASCII serialized origin is defined in [HTML5].

DOMString, ArrayBuffer, BufferSource and any are defined in [WEBIDL].

DOMException, AbortError, SyntaxError, NotSupportedError, NotFoundError, NetworkError, SecurityError are defined in [DOM4].

Promise, JSON, JSON.stringify and JSON.parse are defined in [ECMASCRIPT].

The algorithms utf-8 encode, and utf-8 decode are defined in [ENCODING].

IANA media types (formerly known as MIME types) are defined in RFC2046.

A valid MIME type is defined in [HTML5].

The term queue a task is defined in [HTML5].

The term task source is defined in [HTML5].

2.1 Security

The term expressed permission refers to an act by the user, e.g. via user interface or setting or host device platform features, using which the user approves the permission of a browsing context to access the given functionality.

The term ask for forgiveness refers to some form of unobtrusive notification that informs the user of an operation while it is running. UAs SHOULD provide the user with means to ignore similar future operations from the same origin and advertise this to the user.

The term prearranged trust relationship means that the UA has already established a trust relationship for a certain operation using a platform specific mechanism, so that an expressed permission from the user is not any more needed. See also this section in the Security and Privacy document.

The term obtain permission for a certain operation indicates that the UA has either obtained expressed permission, or asks for forgiveness, or ensured a prearranged trust relationship exists.

2.2 NFC specific

NFC stands for Near Field Communications, short-range wireless technology operating at 13.56 MHz which enables communication between devices at a distance less than 10 cm. The NFC communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards, including ISO/IEC 14443 and FeliCa. The NFC standards include ISO/IEC 18092[5] and those defined by the NFC Forum. See https://www.nfc-forum.org/specs/spec_list/ for a complete listing.

An NFC adapter is the software entity in the underlying platform which provides access to NFC functionality implemented in a given hardware element (NFC chip). A device may have multiple NFC adapters, for instance a built-in one, and one attached via USB.

An NFC tag is a passive NFC device. The NFC tag is powered by magnetic induction when an active NFC device is in proximity range. An NFC tag contains a single NDEF message.

Note

The way of reading the message may happen through proprietary technologies, which require the reader and the tag to be of the same manufacturer. Implementations are expected to encapsulate this.

An NFC peer is an active, powered device, which can interact with other devices in order to exchange data using NFC.

An NFC device is either an NFC peer, or an NFC tag.

An NDEF message encapsulates one or more application-defined NDEF records. NDEF is an abbreviation for NFC Forum Data Exchange Format, a lightweight binary message format. NDEF messages can be stored on an NFC tag or exchanged between NFC-enabled devices.

The term NFC content is a synonym for NDEF message, which can originate either from an NFC tag or an NFC peer.

An NDEF record is a part of an NDEF message that has a single associated type information to its payload. It contains a Type Name Format (TNF) field, the payload size, the payload type, an optional identifier which is a URL, and a payload of maximum size of 2^32-1 bytes. The NFC Forum has standardized a small set of useful data types for use in NDEF records, for instance text, URL, and binary data such as media. In addition, there are record types designed for more complex interactions, such as Smart Poster, and handover records.

The TNF (Type Name Format) field of the NDEF record can take binary values denoting the following NDEF record payload types:

TNF value NDEF record type
0 Empty
1 NFC Forum Well-Known Type
2 Media Type
3 Absolute URI
4 NFC Forum External Type
5 Unknown
6 Unchanged
7 Reserved

NFC Forum Well-Known Type includes record types text, URI, Smart Poster (containing an URL or other data, and possible actions).

An NFC watch is a mechanism used to watch for available Web NFC messages fulfilling certain criteria. It is defined in more detail in The watch() method section.

A Web NFC record is an NDEF record of External Type, specific to Web NFC. It indicates that the containing NDEF message is targeted for browsing contexts using this API and contains information useful for handling the NDEF message with the algorithms defined in this specification. The format of a Web NFC record is as follows:

The Web NFC Id is a URL according to [RFC3986], specifically an ASCII serialized origin with "https" scheme, and optionally followed by a URL path. This allows matching Web NFC content with URL patterns specified by NFC watches.

A Web NFC message consists of a set of the NDEF records and a single Web NFC record.

Note

The position of the Web NFC record within the Web NFC message is implementation specific, this specification only mandates its existence for a Web NFC message. It is not mandatory to a NDEF message.

The term Web NFC content denotes all Web NFC messages contained within an NDEF message, identified by the Web NFC Id within the NDEF message. This version of the specification supports one Web NFC message per NDEF message.

Note

As part of the NDEF record, an NDEF Id field may be present for application specific usages. According to the [NFC-STANDARDS] it contains a URL with the maximum length of 256 octets. This URL is used for identifying the payload in an application specific way. Although the NDEF Id could be used for containing e.g. an ASCII serialized origin associated with the NDEF record, it is not used in this version of the specification for record-level identification, since the message-level identification is handled by the Web NFC Id. Also, the content of the NDEF Id is also contained in the Web NFC Id, and since NFC tags are rather small storage units, this duplication is avoided in this version. When multiple Web NFC messages eventually will be supported within a single NDEF message, it would likely use the NDEF Id to store the same identifier for each NDEF record which is part of a given Web NFC message, which identifier will likely be an ASCII serialized origin associated with the Web NFC content.

The term trusted integrity NFC content refers to an NDEF message, or an NDEF record, which can be trusted for data integrity, i.e. the content is not changed by third parties between writing and reading.

An NFC handover defines NFC Forum Well Known Types and the corresponding message structure that allows negotiation and activation of an alternative communication carrier, such as Bluetooth or WiFi. The negotiated communication carrier would then be used (separately) to perform certain activities between the two devices, such as sending photos to the other device, printing to a Bluetooth printer or streaming video to a television set.

3. Introduction

This section is non-normative.

In general, there are three groups of user scenarios for NFC:

NFC works using magnetic induction, meaning that the reader will emit a small electric charge which then creates a magnetic field. This field powers the passive device which turns it into electrical impulses to communicate data. Thus, when the devices are within range, a read is always performed (see NFC Analog Specification and NFC Digital Protocol, NFC Forum, 2006). The peer-to-peer connection works in a similar way, as the device periodically switches into a so-called initiator mode in order to scan for targets, then later to fall back into target mode. If a target is found, the data is read the same way as for tags.

As NFC is based on existing RFID standards, many NFC chipsets support reading RFIDs tags, but many of these are only supported by single vendors and not part of the NFC standards. Though certain devices support reading and writing to these, it is not a goal of this document to support proprietary tags or support interoperability with legacy systems.

The NFC Forum has mandated the support of four different tag types to be operable with NFC devices. The same is required on operating systems such as Android.

  1. NFC Forum Type 1: This tag is based on the ISO/IEC 14443-3A (also known as NFC-A, as defined in ISO/IEC 14443-3:2011, Part 3: Initialization and anticollision). The tags are rewritable and can be configured to become read-only. Memory size can be between 96 bytes and 2 Kbytes. Communication speed is 106 kbit/sec.
  2. NFC Forum Type 2: This tag is also based on the ISO/IEC 14443-3A (NFC-A). The tags are rewritable and can be configured to become read-only. Memory size can be between 48 bytes and 2 Kbytes. Communication speed is 106 kbit/sec. In contrast to Type 1, Type 2 has anti-collision protection for dealing with multiple tags within the NFC field.
  3. NFC Forum Type 3: This tag is based on the Japanese Industrial Standard (JIS) X 6319-4, commonly known as FeliCa. The tags are preconfigured to be either rewritable or read-only. Memory availability is variable, theoretical memory limit is 1MByte per service. Communication speed is 106 kbit/sec. Like Type 2, it supports anti-collision protection.
  4. NFC Forum Type 4 (November 2010): This tag is based on the ISO/IEC 14443 like Type 1 and 2, but it support either NFC-A or NFC-B for communication. On top of that the tag may support the Data Exchange Protocol (aka ISO-DEP) defined in ISO/IEC 14443 (ISO/IEC 14443-4:2008 Part 4: Transmission protocol). Like Type 3, the tags are preconfigured to be either rewritable or read-only. Variable memory, up to 32 KB per service. Supports three different communication speeds 106 or 212 or 424 Kbits/s.

In addition to data types standardized for NDEF records by the NFC Forum, many commercial products such as bus cards, door openers etc use different card specific data and protocol extensions which require specific NFC chips (same vendor of card and reader) in order to function.

Card emulation mode capabilities also depend on the NFC chip in the device. For payments, a Secure Element is often needed.

Note

This document does not aim supporting all possible use cases of NFC technology, but only a few use cases which are considered relevant to be used by web pages in browsers, using the browser security model.

4. Examples

This section is non-normative.

This section shows how developers can make use of the various features of this specification.

Example 1: Read and update data stored on tag
navigator.nfc.requestAdapter().then((adapter) => {
  adapter.watch({}, (message, url) => {
    console.log("NDEF message received from URL " + url);
    if (message[0].kind == 'empty') {
      adapter.pushMessage([
        {
          kind: "text",
          type: "",
          data: "Initializing tag"
        }
      ]);
    }
    processMessage(message);
  });
});

function processMessage(message) {
  message.forEach((record) => {
    if (record.kind == "string") {
      console.log(“Data is string: “ + data);
    } else if (record.kind == "json") {
      processJSON(record.data);
    } else if (record.kind == "url") {
    console.log("Data is URL: " + record.data;
    } else if (record.kind == "opaque") {
      processBinary(data);
  });
};

function processBinary(data) {
  console.log("Known (string) binary data: ");
  console.log(String.fromCharCode.apply(null, new Uint16Array(data)));
};

function processJSON(data) {
  var obj = JSON.parse(data);
  console.log("JSON data: " + obj.myProperty.toString());
};
Example 2: Sending data to a peer device
navigator.nfc.requestAdapter().then((adapter) => {
  adapter.pushMessage([
    {
      kind: "text",
      type: "",
      data: "Data meant for peers"
    }
  ]).then(() => {
    console.log("Message sent.")
  }).catch(() => {
    console.log("Send failed :-( try again.")
  });
});
Example 3: Save and restore game progress with another device
navigator.nfc.requestAdapter().then((adapter) => {
  console.log("Awaiting game state");

  adapter.watch({ url: "*://mydomain/mygame/*" }, (message, url) => {
    console.log("Game state received from: " + url;
    console.log("Stored state: " + message.data);

    // Now do some calculations and then update the state.
    // ...
    adapter.pushMessage([ data: { level: 3, points: 4500, lives: 3 } ])
    .then(() => { console.log("We have stored your current game state.") })
    .catch(() => { console.log("Failed updating game state, try again.") });
  };
});

5. Use Cases

This section is non-normative.

A few Web NFC user scenarios are described in the Use Cases document. These user scenarios can be grouped by criteria based on security, privacy and feature categories, resulting in generic flows as follows.

5.1 Reading NFC tags

  1. Reading NFC tags containing a Web NFC message, when a web page using the Web NFC API is open and in focus. For instance, a web page instructs the user to tap an NFC tag, and then receives information from the tag.
  2. Reading NFC tags containing other than Web NFC message, when a web page using the Web NFC API is open and in focus.
  3. Reading NFC tags when no web site using the Web NFC API is open or in focus. This use case is not supported in this version of the specification, and is has low priority for future versions as well.

5.2 Writing to NFC tags

The user opens a web page which can write an NFC tag. The write operations may be one of the following:

  1. Writing to an empty NFC tag.
  2. Writing to NFC tags which already contains a Web NFC message with a different Web NFC Id (i.e. overwriting a web-specific tag).
  3. Writing to NFC tags which already contains a Web NFC message with the same Web NFC Id (i.e. updating own tag).
  4. Writing to other, writable NFC tags (i.e. overwriting a generic tag).

Note that an NFC write operation to an NFC tag always involves also a read operation.

5.3 Sending data to NFC peer devices

In general, sending data to another Web NFC capable device requires that on the initiating device the user would first have to navigate to a web site. The user would then touch the device against another Web NFC equipped device, and data transfer would occur. On the receiving device the UA will dispatch the content to an application registered and eligible to handle the content, and if that application is a browser which has a web page open and in focus that uses the Web NFC API and has set up a NFC watch to listen to Web NFC content, then the content is delivered to the web page through the parameters of an NFCMessageCallback.

5.4 Handover to another wireless connection type

NFC supports handover protocols to Bluetooth or WiFi connectivity for the purpose of larger volume data transfer. The user touches another NFC capable device, and as a result configuration data is sent for a new Bluetooth or WiFi connection, which is then established between the devices. This use case is not supported in this version of the specification.

5.5 Payment scenarios

The user buys goods in a store, and payments options include NFC. In general, touching the device to the point of sales terminal receiver area will result in a transaction between the secure element from the device and the point of sales terminal. With the Web NFC API, if the user navigates to a web site before paying, there may be interaction with that site regarding the payment, e.g. the user could get points and discounts, or get delivered application or service specific data (e.g. tickets, keys, etc) to the device. This use case is not supported in this version of the specification.

6. Features

This section is non-normative.

High level features for the Web NFC specification include the following:

  1. Support devices with single or multiple NFC adapters. If there are multiple adapters present when requesting an NFC adapter then the UA MAY display a dialog for selecting one of them, or MAY otherwise choose a default adapter based on user settings or internal policy.
  2. Support communication with active (powered devices such as readers, phones) and passive (smart cards, tags, etc) devices.
  3. Allow users to act on (e.g. read, write or transceive) discovered NFC devices (passive and active) as well as access the payload which were read in the process as Web NFC messages.
  4. Allow users to write a payload via NDEF records to compatible devices, such as writeable tags, when they come in range, as Web NFC messages.
  5. [future] Allow manual connection for various technologies such as NFC-A and NFC-F depending on the secondary device.
  6. [future] Allow NFC handover to Bluetooth or WiFi.
  7. [future] Allow card emulation with secure element or host card emulation.

NFC is usually deeply integrated into device platforms (e.g. Android, Windows, etc), because end-to-end user experience implications (e.g. users need to be presented platform specific dialogs for selecting applications and actions). Also, privacy and security related issues require platform specific solutions.

The various integrated technologies, wide variety of use cases, and platform integration issues make standardization of NFC for the web a challenge. Therefore this document makes a few simplifications in what use cases and data types are possible to handle by users of this API:

7. Security and Privacy

The trust model, attacker model, threat model and possible mitigation proposals for the Web NFC API are presented in the Security and Privacy document. This section presents the chosen security and privacy model through normative requirements to implementations.

7.1 Chain of trust

Web pages using the Web NFC API are not trusted. This means that the user needs to be aware of exactly what a web page is intending to do with NFC at any given moment. Implementations need to make sure that when the user authorizes a method of this API, then only that action is run, without side effects, and exactly in the context and the number of times the user allows the execution of NFC related operations, according to the algorithmic steps detailed in this specification.

The integrity of NFC content SHOULD NOT be trusted when used for implementing security policies, for instance the authenticity of origins saved in the NDEF Id field, unless a prearranged trust relationship (such as encryption and other means) exists.

7.2 Threats

The main threats are summarized in the Security and Privacy document.

In this specification the following threats are handled with the highest priority:

7.3 Permissions and user prompts

This specification attempts to help minimizing the user prompts needed to use the Web NFC API and tries to involve implicit policies which can address the threats. However, this specification does not describe, nor does it mandate specific user prompting policies. The term obtain permission is used for acquiring trust for a given operation.

Note

The Permissions API is suggested to be used by UAs for implementing NFC related [permissions] in order to minimize the need for user prompting. The suggested permission name is "nfc". This allows saving user permissions for a given origin in a persistent database until revocation.

All expressed permissions that are preserved beyond the current browsing session MUST be revocable.

7.4 Security policies

This section is non-normative.

This section summarizes the security policies which are specified as normative requirements in the respective algorithms of this specification:

8. Data Representation

8.1 The NFCRecord dictionary

The content of any NDEF record is exposed by the NFCRecord dictionary: 

enum NFCRecordType {
    "empty",
    "text",
    "url",
    "json",
    "opaque"
};

typedef (DOMString or unrestricted double or object or ArrayBuffer) NFCRecordData;

dictionary NFCRecord {
    NFCRecordType kind;
    USVString     type;
    NFCRecordData data;
};

The NFCRecord.type property represents the IANA media type of the NDEF record payload.

The NFCRecord.data property represents the payload data of the NDEF record with an appropriate ECMAScript type, which depends on the IANA media type.

The mapping from data types of an NFCRecord to and from NDEF record types is presented in the algorithmic steps which handle the data and described in the Receiving and parsing content and Writing or pushing content sections.

8.2 The NFCMessage dictionary

The content of any Web NFC message is exposed by the NFCMessage dictionary: 

dictionary NFCMessage {
    sequence<NFCRecord> data;
    USVString           url;
};

The NFCMessage.url property represents the Web NFC Id of the Web NFC message.

The NFCMessage.data property represents the NDEF message defining the Web NFC message.

8.3 Data mapping

A JSON compatible IANA media type is defined by the following ABNF: 

      "application/" ("json" / <VCHAR except '/' and "*"> "+json")

The mapping from data types of an NFCRecord to NDEF record types, as used in the Writing or pushing content section is as follows:

NFCRecord kind NFCRecord type NFCRecord data NDEF record type
"empty" not used not used NFC Forum Empty Type (TNF=0)
"text" not used DOMString NFC Forum Well Known Type (TNF=1) with type Text
"url" not used DOMString NFC Forum Well Known Type (TNF=1) with type URI
"json" JSON compatible IANA media type null or DOMString or Number or Object Media Type as defined in [RFC2046] (TNF=2) with IANA media type specified in the type attribute.
"opaque" IANA media type ArrayBuffer Media Type as defined in [RFC2046] (TNF=2)
"opaque" "" (empty) ArrayBuffer or typed array NFC Forum External Type (TNF=4)

The mapping from NDEF record types to NFCRecord, as used for incoming NDEF messages described in the Receiving and parsing content section, is as follows:

NDEF record type NFCRecord kind NFCRecord type NFCRecord data
NFC Forum Empty Type (TNF=0) "empty" "" null
NFC Forum Well Known Type (TNF=1) with type Text "text" "text/plain" DOMString
NFC Forum Well Known Type (TNF=1) with type URI "url" "text/plain" DOMString
NFC Forum Well Known Type (TNF=1) with type Smart Poster "url" "text/plain" DOMString
Absolute URI as defined in [RFC3986] (TNF=3) "url" "text/plain" DOMString
Media Type as defined in [RFC2046] (TNF=2) with JSON compatible IANA media type "json" The IANA media type used in the NDEF record null or DOMString or Number or Object
Media Type as defined in [RFC2046] (TNF=2) "opaque" The IANA media type used in the NDEF record ArrayBuffer
NFC Forum External Type (TNF=4) with type other than urn:nfc:ext:w3.org:webnfc* "opaque" "application/octet-stream" ArrayBuffer
Any other NDEF record type "opaque" "application/octet-stream" ArrayBuffer

The Web NFC records MUST NOT be exposed to client browsing contexts.

9. Extensions to the Navigator interface

The HTML document defines a Navigator interface [HTML] which this specification extends. 

partial interface Navigator {
    readonly    attribute NFC nfc;
};

9.1 The nfc attribute

On getting the nfc attribute, the UA MUST return the NFC object, which provides NFC related functionality.

10. The NFC interface

An NFC instance provides a way for the browsing context to obtain an NFC adapter providing NFC functionality. Implementations MAY expose multiple adapters. 
interface NFC {
    Promise<NFCAdapter> requestAdapter();
};

Instances of NFCAdapter are created with the internal slots described in the following table:

Internal Slot Description (non-normative)
[[receivedMessage]] An NFCMessage to hold the last received message, initially set to null.
[[suspended]] A boolean flag indicating whether the adapter is suspended or not, initially false.
[[tagMessage]] An NFCMessage to hold the NDEF message to be pushed to a NFC tag, initially set to null.
[[tagTimer]] A timer which can perform an action after timeout milliseconds.
[[peerMessage]] An NFCMessage to hold the NDEF message to be pushed to a NFC peer, initially set to null.
[[peerTimer]] A timer which can perform an action after timeout milliseconds.
[[watchList]] A list of NFC watches initially set to empty list.

The NFC.requestAdapter() method, when invoked MUST return a new promise promise and run the following steps in parallel:

  1. If the incumbent settings object is not a secure context, reject promise with "SecurityError", and abort these steps.
    Note
    Browsers may ignore this rule for development purposes only.
  2. If there is no support for NFC adapter handling functionality in hardware, software, or due to physical incompatibility, reject promise with "NotSupportedError", and abort these steps.
  3. Let adapter be null.
    Note

    Each Window object has a separate NFCAdapter instance. The visibility and focus state of the Window object determines the suspended state of the associated NFCAdapter instance.

  4. If there is a default NFC adapter, set adapter to the corresponding NFCAdapter object, or if that does not exist, a new NFCAdapter object which is bound to work with the default NFC adapter. Resolve promise with adapter, and terminate these steps.
  5. Otherwise, make a request to enumerate available NFC adapters. If the request fails, reject promise with "NotFoundError", and abort these steps.
  6. If the request is successful, select one of the NFC adapters based on the following algorithm:
    1. Let adapter be a new NFCAdapter object.
    2. If there is only one NFC adapter, then bind adapter to that.
    3. Otherwise, if there are multiple NFC adapters available, and there is a system or user setting available with a preference to select the default adapter, then bind adapter to that.
    4. Otherwise, the UA MAY pop up a user dialog for selecting one of the NFC adapter, and bind adapter to the selected one.
    5. Otherwise if user prompt is blocked or canceled, bind adapter to the first built-in NFC adapter
    6. Otherwise, if no built-in adapters are found, bind adapter the first external (e.g. USB) NFC adapter.
  7. Resolve promise with adapter.

11. The NFCAdapter interface

The NFCAdapter represents an NFC hardware device which can read and write data. It allows for sending Web NFC messages to NFC tags or NFC peers within range, and to set up and cancel NFC watches to handle incoming Web NFC messages either from an NFC tag or an NFC peer. 
interface NFCAdapter {
    Promise<void> pushMessage(NFCMessage message, NFCPushOptions options);
    void          cancelPush(NFCPushTarget target);
    Promise<long> watch(NFCWatchOptions options, MessageCallback callback);
    Promise<void> unwatch(long id);
};

callback MessageCallback = void (NFCMessage message);
Note

In later versions cancelPush() and unwatch() may be obsoleted by cancelable Promises used with pushMessage() and watch(), respectively.

11.1 The NFCPushOptions dictionary

enum NFCPushTarget {
    "tag",
    "peer",
    "any"
};

dictionary NFCPushOptions {
    NFCPushTarget target = "any";
    unsigned long timeout;
};

The NFCPushOptions.target property denotes the intended target for the pending pushMessage() operation.

The NFCPushOptions.timeout property denotes the timeout for the pending pushMessage() operation expressed in milliseconds. The default value is implementation-dependent. The value Infinity means there is no timeout. After the timeout expires, the message set for sending is cleared, an error is returned, and a new Web NFC message can be set for sending.

11.2 The NFCWatchOptions dictionary

To describe which messages an application is interested in, the NFCWatchOptions dictionary is used: 

enum NFCWatchMode {
    "web-nfc-only",
    "any"
};

dictionary NFCWatchOptions {
    USVString    url = "";
    USVString    kind = "";
    USVString    type = "";
    NFCWatchMode mode = "web-nfc-only";
};

The NFCWatchOptions.url property denotes the URL pattern which is used for matching the URL origin and URL path of the Web NFC message which is stored in the Web NFC record. The default value "" means that no matching happens.

The NFCWatchOptions.kind property denotes the string value which is used for matching the kind property of each NFCRecord object in a Web NFC message. The default value "" means that no matching happens.

The NFCWatchOptions.type property denotes the match pattern which is used for matching the type property of each NFCRecord object in a Web NFC message. The default value "" means that no matching happens.

The NFCWatchOptions.mode property tells whether only Web NFC content or any NFC content will be watched.

The "web-nfc-only" value means that only those NDEF messages are exposed which contain a Web NFC record, i.e. which are meant for web pages.

The "any" value means that all NDEF messages are exposed.

Example 4: Filter accepting only JSON content from https://www.w3.org
var watchOptions = {
  url: "https://www.w3.org/*",  // any path from the domain is accepted
  kind: "json",
  type: "application/*+json"  // any JSON-based IANA media type
}
Example 5: Filter which only accept binary content from a given path but any domain
var watchOptions = {
  url: "*://*/info/restaurant/daily-menu/",  // accepted from any domain
  kind: "opaque",
  type: "application/octet-stream"
}

11.3 Writing or pushing content

This section describes how to write an NDEF message to an NFC tag or how to push it to an NFC peer device next time when they get into proximity range, or until a timeout expires. At any time there is at maximum two Web NFC messages that can be set for sending for an origin: one targeted to NFC tags and one to NFC peers. When there is a Web NFC message set for sending to "any" target, then no more messages are accepted to be set until the current message is sent, or a timeout happens, or the sending is canceled by the cancelPush() method.

11.3.1 The pushMessage() method

The NFCAdapter.pushMessage(message, options) method, when invoked, MUST run the push a message algorithm:

  1. Return a new Promise promise, and then continue running this algorithm in parallel.
  2. If any exception occurs while running these steps, reject promise with that exception, and abort these steps.
  3. If there are any existing instance of this algorithm running for the current NFC adapter whose target is equal to options.target, abort that instance of this algorithm by rejecting its promise with "AbortError".
    Note

    In other words, the current invocation of pushMessage() rejects and replaces existing running invocations handling the same options.target.

    Note

    Implementations are expected to clean up state on aborting these steps, e.g. reset the related timer (either this@[[tagTimer]] or this@[[peerTimer]]), clear the related message (either this@[[tagMessage]] or this@[[peerMessage]]), as well as release any resources bound to NFC functionality, so that new invocations of this algorithm do not depend on previous invocations.

  4. If the incumbent settings object is not a secure context, reject promise with "SecurityError", and abort these steps.
    Note
    Browsers may ignore this rule for development purposes only.
  5. An implementation MAY reject promise with "NotSupportedError", and abort these steps.
    Note
    The UA might terminate message push at this point. The reasons for terminations are implementation details. For example, the user could have has set a preference to allow a given origin only to read, write, or send data to peers. Also, the implementation might be unable to support the operation requested.
  6. If the obtain push permission steps return false, then reject promise with "SecurityError", and abort these steps.
  7. If the message parameter is an empty sequence, then reject promise with "SyntaxError", and abort these steps.
  8. Let output be the notation for the NDEF message to be created by UA, as the result of passing message to create Web NFC message. If this threw an exception, reject promise with that exception and abort these steps.
  9. If options.timeout value is not valid or not supported by the UA, reject promise with "SyntaxError", and abort these steps.
  10. If target has the value "tag", then
    1. Set this@[[tagMessage]] (referred to as message in this instance of the algorithm) to output.
    2. If options.timeout value is not Infinity, start the timer this@[[tagTimer]] (referred to as timer in this instance of the algorithm) with the timeout value set to options.timeout.
  11. If target has the value "peer", then
    1. Set this@[[peerMessage]] (referred to as message in this instance of the algorithm) to output.
    2. If options.timeout value is not Infinity, start the timer this@[[peerTimer]] (referred to as timer in this instance of the algorithm) with the timeout value set to options.timeout.
  12. Wait until one of the following events happens:
    • The timer expires, reject promise with "TimeoutError" and abort these steps.
    • If timer is active, and the cancelPush() method is called, reject promise with "AbortError", as described in the cancelPush() algorithm.
    • When an NFC device device comes within communication range,
      1. If this@[[suspended]] is true, then abort these steps without rejecting promise.
        Note

        The promise will then be pending until a timeout, or until this@[[suspended]] becomes false and a new tap happens.

      2. If device is an NFC tag, and tagMessage is null, then reject promise with "InvalidAccessError" and abort these steps.
      3. If device is an NFC peer, and peerMessage is null, then reject promise with "InvalidAccessError" and abort these steps.
      4. Initiate data transfer to device.
      5. If the connection is lost during the transfer, or an error occured, reject promise with "NetworkError" and terminate this algorithm.
      6. Otherwise if the transfer is successful, cancel timer and set message to null and then resolve promise.

11.3.1.1 Obtaining push permission

To obtain push permission, run these steps:

  1. If a prearranged trust relationship exists, then return true.
  2. Otherwise, if an expressed permission has been granted to the origin using the Permissions API, then return true.
  3. Return false.

11.3.1.2 Creating Web NFC message

To create Web NFC message given a message run these steps:

  1. Let output be the notation for the NDEF message to be created by the UA as a result of these steps.
  2. For each NFCRecord record in the sequence message.data, run the following steps, or make sure that the underlying platform provides equivalent values to ndef:
    1. If record.kind is "empty", then Let ndef be the result of passing record to map empty record to NDEF. If this threw an exception, reject promise with that exception and abort these steps.
    2. Otherwise, if record.kind is "text", then let ndef be the result of passing record to map text to NDEF. If this threw an exception, reject promise with that exception and abort these steps.
    3. Otherwise, if record.kind is "url", then let ndef the be result of passing record to map a URL to NDEF. If this threw an exception, reject promise with that exception and abort these steps.
    4. Otherwise, if record.kind is "json", then let ndef the be result of passing record to map a JSON object to NDEF. If this threw an exception, reject promise with that exception and abort these steps.
    5. Otherwise, if record.kind is "opaque", then let ndef the be result of passing record to map binary data to NDEF. If this threw an exception, reject promise with that exception and abort these steps.
    6. Otherwise, if record.kind is undefined, then:
      1. If record.data is instance of ArrayBuffer, then set record.type to "application/octet-stream" and run the map binary data to NDEF steps.
      2. Otherwise, if type of record.data is "object", then set record.type to "application/json" and run the map a JSON object to NDEF steps.
      3. Otherwise, if type of record.data is "number" or "string", then set record.type to "plain/text" and run the map text to NDEF steps.
      4. Otherwise reject promise with "SyntaxError", and abort these steps.
    7. Add ndef to output.
  3. Let webnfc be the result of invoking create a Web NFC record.
  4. Add webnfc to output.
    Note

    Implementations may choose the location of the Web NFC record within the NDEF message.

11.3.1.3 Mapping empty record to NDEF

To map empty record to NDEF given a record, run these steps:

  1. Let ndef be the notation for the NDEF record to be created by the UA.
  2. Set the ndef.TNF field to 0 (NFC Empty Type record).
  3. Set ndef.TYPE_LENGTH, ndef.ID_LENGTH and ndef.PAYLOAD_LENGTH fields to 0, and omit the associated fields from the NDEF record: ndef.TYPE, ndef.ID, ndef.PAYLOAD.
  4. Return ndef.

11.3.1.4 Mapping string to NDEF

To map text to NDEF given a record, run these steps:

Note

This kind is useful when clients specifically want to write an NDEF Well Known Type Text record. Other options would be to use the value "opaque" with an explicit IANA media type text type, which allows for better differentiation, e.g. when using "text/xml", or "text/vcard".

  1. If record.data is not a string or number, throw a "SyntaxError" exception, and abort these steps.
  2. If record.type is not a string or starts with "text/", then throw a "SyntaxError" exception, and abort these steps. In addition, UAs MAY check that record.type is an IANA registered media type for text. If not, then the UA MAY throw a "SyntaxError" exception, and abort these steps.
  3. Let language be "en". If record.type includes a lang= parameter, detailing the language encoding (e.g. "text/plain; lang=fr"), then set language to the language code extracted from record.type. If language is not one of the language codes listed in the IANA language registry (or [ISO-639.2]), then UAs MAY throw a "SyntaxError" exception, and abort these steps.
    Note

    Note that lang= is not standard parameter to IANA media types, but it is used in this specification in order to maintain compatibility with NFC specifications.

  4. Let ndef be the notation for the NDEF record to be created by the UA.
  5. Set the ndef.TNF field to 1 (NFC Well Known Type).
  6. Set the def.TYPE field to "T" (value 0x54 following NFC binary encoding).
  7. Set the ndef.PAYLOAD field to record.data encoded according to the [NFC-STANDARDS], NFC Forum Text Record Type Definition specification:
    1. The first octet is a status byte containing bit flags.
      1. If record.type contains the parameter "charset=UTF-8" (e.g. "text/plain; charset=UTF-8;"), then set bit 7 (MSB) to 0 (UTF-8 encoding), otherwise to 1 (UTF-16 encoding).
      2. Set bit 6 to 0.
      3. Set bits 5 to 0 to the length of the language string.
    2. Set the consecutive octets of ndef.PAYLOAD to the value of language encoded as US-ASCII.
    3. Set the consecutive payload octets to record.data in the encoding set by the MSB bit of the first payload octet (by default UTF-16, or UTF-8 on special request).
  8. Return ndef.

11.3.1.5 Mapping URL to NDEF

To map a URL to NDEF given a record, run these steps:

  1. If record.data is not a string, throw a "SyntaxError" exception and abort these steps.
  2. Let ndef be the notation for the NDEF record to be created by the UA.
  3. Set the ndef.TNF field to 1 (Well Known Type).
  4. Set the ndef.TYPE field to "U" (0x55 following NFC binary encoding).
  5. Set the ndef.PAYLOAD field to record.data encoded according to the [NFC-STANDARDS], NFC Forum URI Record Type Definition specification: set the first octet according to the applicable scheme abbreviation, and set the rest of the payload bytes to record.data in UTF-8 encoding.
  6. Return ndef.

11.3.1.6 Mapping JSON to NDEF

To map a JSON object to NDEF given a record, run these steps:

  1. Let data be the result of serializing record.data and if that throws, throw a "TypeError" exception and abort these steps.
  2. If record.type doesn't match "application/json", or any other IANA media type for JSON (starting with "application/" and ending with "+json"), throw a "SyntaxError" exception and abort these steps.
  3. Let ndef be the notation for the NDEF record to be created by the UA.
  4. Set the ndef.TNF field to 2 (Media Type).
  5. Set the ndef.TYPE field to record.type.
  6. Set the ndef.PAYLOAD field to data according to the [NFC-STANDARDS], i.e. as an opaque octet stream.
  7. Return ndef.

11.3.1.7 Mapping binary data to NDEF

To map binary data to NDEF given a record, run these steps:

  1. If record.data is not of instance of ArrayBuffer, reject promise with "SyntaxError", and abort these steps.
  2. The UA MAY check if record.type is a valid IANA registered type. If not, then MAY throw a "SyntaxError" exception and abort these steps.
  3. Let ndef be the notation for the NDEF record to be created by the UA.
  4. Set the ndef.TNF field to 2 (Media Type).
  5. Set the ndef.TYPE field to record.type.
  6. Set the ndef.PAYLOAD field to record.data according to the [NFC-STANDARDS], i.e. as an opaque octet stream.
  7. Return ndef.

11.3.1.8 Creating a Web NFC record

To create a Web NFC record, run these steps:

  1. Let ndef be the notation for the NDEF record to be created by the UA.
  2. Set ndef.TNF to 4 (NDEF External Type).
  3. Set ndef.TYPE to "urn:nfc:ext:w3.org:webnfc".
  4. Set ndef.PAYLOAD to the URL path of the browsing context, encoded as UTF-16. This is going to be used by NFC watch filters.
    Note

    In future versions a list of "allowed-origins" may be supported. It is still up for discussions due to security issues. See the Security and Privacy document.

  5. Return ndef.

11.3.2 The cancelPush method

The NFCAdapter.cancelPush(target) method, when invoked, MUST run cancel push algorithm:

  1. If the incumbent settings object is not a secure context, reject promise with "SecurityError", and abort these steps.
    Note
    Browsers may ignore this rule for development purposes only.
  2. If the parameter target is "tag", and if this@[[tagMessage]] is non-null, then
    1. Reset this@[[tagTimer]].
    2. Set this@[[tagMessage]] to null.
    3. Reject the pending promise in the connected instance of the pushMessage() algorithm with "AbortError".
  3. If the parameter target is "peer", and if this@[[peerMessage]] is non-null, then
    1. Reset this@[[peerTimer]].
    2. Set this@[[peerMessage]] to null.
    3. Reject the pending promise in the connected instance of the pushMessage() algorithm with "AbortError".

11.4 Watching for content

In order to receive NFC content, the client needs to call the NFCAdapter.watch() to opt into content of interest.

11.4.1 Match patterns

A match pattern is defined by the following ABNF: 

          match-pattern       = top-level type name "/" [ tree "." ] subtype name [ "+" suffix ] [ ";" parameters ]
          top-level type name = "*" / <VCHAR except '/' and "*">
          subtype name        = "*" / <VCHAR except '+'>
A match pattern is a glob used for matching IANA media types, for instance the pattern 'application/*+json' matches 'application/calendar+json', but does not match 'application/json'. The pattern '*/*json', on the other hand, matches both.

11.4.2 URL patterns

A URL pattern is a URL which may contain the '*' wildcard character. It consists of a scheme, a host and (optionally) a path, defined by the following ABNF: 

          url-pattern = scheme "://" host path
          scheme      = "*" / "https"
          host        = "*" / "*." <VCHAR except "/" and "*">
          path        = "/" <VCHAR>

Most characters match themselves, however '*' (wildcard) matches a sequence of visible characters. A URL pattern that doesn't conform to the above ABNF is a non-match.

Note

Though '*' matches a sequence of characters, only URLs with scheme "https" are accepted in the algorithms taking a URL pattern.

For example, '*://*.mydomain.com/*' will match 'https://services.mydomain.com/myservice1/myapp2/' and 'https://info.mydomain.com/general/'.

11.4.3 The watch() method

This method enables listening to incoming NDEF messages. The NFC content to which clients listen can be filtered based on its data type, and based on the URL path of the browsing context which has been saved to the Web NFC record of the NFC content. The latter is matched against URL patterns used in NFC watches.

An NFC watch is referring to a NFCWatchOptions filter saved together with the NFCAdapter instance it belongs to, and a locally unique identifier which is used for cancellation. The section Receiving and parsing content uses NFC watches to match incoming NFC content.

Multiple consecutive calls to the watch() method from the same origin create filters which are in OR relationship.

Watch filters are grouped by NFC adapter.

When the NFCAdapter.watch(options, callback) method is invoked, the UA MUST run the following NFC watch algorithm:

  1. Let promise be a new Promise object.
  2. Return promise and continue the following steps in parallel.
  3. If any exception occurs while running these steps, reject promise with that exception, and abort these steps.
  4. If the incumbent settings object is not a secure context, reject promise with "SecurityError", and abort these steps.
    Note
    Browsers may ignore this rule for development purposes only.
  5. If there is no support for the functionality of receiving data from an NFC peer or NFC tag in proximity range, reject promise with "NotSupportedError", and terminate this algorithm.
  6. If the obtain watch permission steps return false, then reject promise with "SecurityError", and abort these steps.
  7. If this is the first watch being set up for the current NFC adapter, then make a request to listen to NDEF messages.
  8. If the request fails, reject promise with "NotSupportedError" , and abort these steps.
  9. Let watchId be a number that will identify this NFC watch.
  10. Add watchId, options, and callback together as an NFC watch to this@[[watchList]].
  11. Resolve promise with watchId.
  12. If the browsing context loses focus (e.g. the user navigated to another page), then the registered watches still SHOULD continue to exist, but SHOULD become paused, i.e. the UA SHOULD NOT check and use them until the focus is regained.

To obtain watch permission, run these steps:

  1. If there is a prearranged trust relationship, return true.
  2. Otherwise, if the user has earlier denied permission for the calling origin for all future calls of watch() as well, then return false.
  3. Otherwise, UAs SHOULD ask for forgiveness with relevant information displayed to the user.
    Note

    The ask for forgiveness interaction might show choices like "block now" or "block forever", etc. If the user has chosen to "block forever" the given origin, it is the responsibility of the UA to remember these user choices for each origin, regardless of which NFC adapter is used, and consult them on later invocations.

    Note

    In this step UAs are advised to notify users about that reading NFC content may indirectly reveal the physical location of the user. In addition, if "any" NfcWatchMode is used, then also include in this information that the origin is requesting to read not only NFC content meant for web pages, but any NFC content.

  4. Return true.

11.4.4 The unwatch() method

When the NFCAdapter.unwatch(id) method is invoked, the UA MUST return a Promise promise and run the following steps in parallel.

  1. If the incumbent settings object is not a secure context, reject promise with "SecurityError", and abort these steps.
    Note
    Browsers may ignore this rule for development purposes only.
  2. If the parameter id is undefined, then remove all watches and filters set by successive calls of the NFC watch() method on the current NFC adapter.
  3. Otherwise, if the parameter id matches the local identifier of one of the previously set up watches, remove the corresponding watch.
  4. Otherwise, reject promise with "NotFoundError", and abort these steps.
  5. If there are no more watches on the current NFC adapter, then make a request to stop listening to NDEF messages on that adapter.
  6. Resolve promise.

11.5 Receiving and parsing content

If there are any NFC watches set up for any NFC adapter in their NFCAdapter@[[watchList]], then UAs MUST listen to NDEF messages, according to step 9 of the NFC watch algorithm.

11.5.1 The NDEF parsing algorithm

When the UA is to receive an NDEF message it MUST run the following algorithm:
  1. Let input be the notation for the NDEF message which has been received.
    Note

    This is a placeholder for a possible future feature. In this step, implementations MAY check if the origin of the incumbent settings object matches the Web NFC Id of input. If yes, and also prearranged trust relationship exists so that input is trusted integrity NFC content, then same-origin policies MAY be applied.

    Note

    This is a placeholder for a possible future feature. In this step, implementations MAY check if any of the URL patterns saved in the Web NFC record (in the future) match the origin of the incumbent settings object. If yes, and also if prearranged trust relationship exists so that input is trusted integrity NFC content, then allowed-origin policies MAY be applied.

  2. Let message be a new NFCMessage object.
  3. Let message.url be null, used for storing the Web NFC Id of message.
  4. For each NDEF record which is part of input, run the following sub-steps for parsing NDEF record:
    1. Let ndef be the notation for the current NDEF record. The fields of ndef are described by the [NFC-STANDARDS].
    2. Let record be a new NFCRecord object.
    3. If ndef.TNF is 0 (NFC Empty Record), then set record.kind to "empty", record.type to "", and record.data to null.
    4. If ndef.TNF is 1 (NFC Well Known Type Record), and ndef.TYPE is "T" (value 0x54 following NFC binary encoding), then run the following sub-steps for parsing NDEF Text record, or ensure that the underlying platform provides equivalent values to the record object properties:
      1. Set record.kind to "text".
      2. Set record.type to "text/plain".
      3. Read the first octet of ndef.PAYLOAD. Let offset be the value given by bits 5 to 0 of the first payload octet.
      4. Let language be the string defined by the consecutive offset number of octets, converted from US-ASCII encoding. Append ";lang=" and then the value of language to record.type.
      5. Set record.data to the string created from the consecutive ndef.PAYLOAD octets, converted to UTF-16 encoding.
    5. If ndef.TNF is 1 (NFC Well Known Type Record), and ndef.TYPE is "U" (value 0x55 in NFC binary encoding), then run the following sub-steps for parsing NDEF URL record, or make sure that the underlying platform provides equivalent values to the record object properties:
      1. Set record.kind to "url".
      2. Set record.type to "text/plain".
      3. Let scheme be the value of the first octet of ndef.PAYLOAD.
      4. If scheme is not 0, then set record.data to the string obtained from mapping the value of scheme to the URL scheme as specified in the [NFC-STANDARDS] URI Record Type Definition specification, Section 3.2.2.
      5. Set record.data to the UTF-16 string converted from the octets of ndef.PAYLOAD except the first octet.
    6. If ndef.TNF is 3 (NFC Absolute URI Type record), then set record.kind to "url", set record.type to "text/plain" and set record.data to the string converted from ndef.PAYLOAD.
    7. If ndef.TNF is 2 (NFC Media Type record), then run the following sub-steps for parsing NDEF Media record, or make sure that the underlying platform provides equivalent values to the record object properties:
      1. If ndef.TYPE matches the match pattern "application/*json", then
        1. Set record.kind to "json".
        2. Set record.type to ndef.TYPE.
        3. Set record.data to the result of converting ndef.PAYLOAD to string.
          Note

          The payload SHOULD NOT be evaluated by UAs for security reasons.

      2. Otherwise,
        1. Set record.kind to "opaque".
        2. Set record.type to ndef.TYPE.
        3. Set record.data to a new ArrayBuffer object constructed from the octets of ndef.PAYLOAD.
    8. If ndef.TNF is 4 (NFC External Type record), and ndef.TYPE is urn:nfc:ext:w3.org:webnfc, then set message.url to the value decoded from ndef.PAYLOAD in UTF-16.
    9. Otherwise, if ndef.TNF is 4 (NFC External Type record), or 5 (NFC Unknown Type record) then run the following sub-steps, or make sure that the underlying platform provides equivalent values to the record object properties:
      1. Set record.kind to "opaque".
      2. If ndef.TYPE is defined, then set record.type to that string value, otherwise to "application/octet-stream.
      3. Set record.data to a new ArrayBuffer object constructed from the octets of ndef.PAYLOAD.
    10. Otherwise, skip to the next NDEF record in input.
    11. Add record to message.data.
  5. Set NFCAdapter@[[receivedMessage]] to message.
  6. If NFCAdapter@[[suspended]] is false, then run the dispatch NFC content algorithm.

11.5.2 Dispatching NFC content

The following steps are used for dispatching received NFC content:

  1. Let message be NFCAdapter@[[receivedMessage]].
  2. For each NFC watch watch that has been registered using the watch() method in this@[[watchList]], run the following sub-steps:
    1. Let options be the NFCWatchOptions saved with watch, and let callback be the registered callback function.
    2. If options.mode is "web-nfc-only", and message.url is null, then skip to the next NFC watch.
    3. Otherwise, if options.mode is "web-nfc-only", and message.url is not null, or if options.mode is "any", then run the following sub-steps:
      1. If message.url does not match the URL pattern stored in options.url, then skip to the next NFC watch.
      2. If options.kind is not equal to any record.kind where record is an element of message, then skip to the next NFC watch.
      3. If options.type is not equal to any record.type where record is an element of message, then skip to the next NFC watch.
      4. Queue a task using the Web NFC task source to invoke the MessageCallbackvar>callback with message as its argument.
      5. Set NFCAdapter@[[receivedMessage]] to null.
  3. Set NFCAdapter@[[receivedMessage]] to null.

11.6 Handling visibility and focus

With the term suspended this specification refers to NFC operations being suspended, i.e. no NFC content is pushed, and no received NFC content is presented via watches while suspended. However, timers instantiated on platform level for the NFCAdapter.pushMessage() method continue running, and if they expire, the event should be recorded and handled next time the execution is resumed, i.e. when the focus event is fired on the Window object.

When the Window object associated with the Document using the Web NFC API becomes visible and in focus, then run the following steps:

  1. Set NFCAdapter@[[suspended]] to false.
  2. If NFCAdapter@[[receivedMessage]] is not null, then run the dispatch NFC content algorithm.

When the Window object associated with the Document using the Web NFC API loses focus, then run the following steps:

  1. Set NFCAdapter@[[suspended]] to true.

A. Changes

The following is a list of substantial changes to the document. For a complete list of changes, see the change log on Github. You can also view the recently closed bugs.

B. Open issues

The following problems are being discussed and need most attention:

This version addresses the issues above, and also other issues.

C. Acknowledgements

The editors would like to express their gratitude to the former editors Luc Yriarte and Samuel Ortiz, and also to Don Coleman, Anne van Kesteren, Domenic Denicola, Jonas Sickling, Jeffrey Yasskin, Alexander Shalamov, Salvatore Iovene, Rijubrata Bhaumik and Anssi Kostiainen for their technical guidance, implementation feedback and support.

D. References

D.1 Normative references

[DOM4]
Anne van Kesteren; Aryeh Gregor; Ms2ger; Alex Russell; Robin Berjon. W3C DOM4. 18 June 2015. W3C Last Call Working Draft. URL: http://www.w3.org/TR/dom/
[ECMASCRIPT]
Allen Wirfs-Brock. ECMA-262 6th Edition, The ECMAScript 2015 Language Specification. June 2015. Standard. URL: http://www.ecma-international.org/ecma-262/6.0/
[ENCODING]
Anne van Kesteren; Joshua Bell; Addison Phillips. Encoding. 16 September 2014. W3C Candidate Recommendation. URL: http://www.w3.org/TR/encoding/
[HTML5]
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 28 October 2014. W3C Recommendation. URL: http://www.w3.org/TR/html5/
[NFC-STANDARDS]
NFC Forum Technical Specifications. 24 July 2006. URL: http://members.nfc-forum.org/specs/spec_list/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[URL]
Anne van Kesteren; Sam Ruby. URL. 9 December 2014. W3C Working Draft. URL: http://www.w3.org/TR/url-1/
[WEBAPPSEC]
Secure Contexts. 17 July 2015. URL: https://w3c.github.io/webappsec/specs/powerfulfeatures
[WEBIDL]
Cameron McCormack; Boris Zbarsky. WebIDL Level 1. 4 August 2015. W3C Working Draft. URL: http://www.w3.org/TR/WebIDL-1/

D.2 Informative references

[ABNF]
D. Crocker, Ed.; P. Overell. Augmented BNF for Syntax Specifications: ABNF. January 2008. Internet Standard. URL: https://tools.ietf.org/html/rfc5234
[ISO-639.2]
Codes for the Representation of Names of Languages. 18 March 2014. URL: https://www.loc.gov/standards/iso639-2/php/code_list.php
[RFC2046]
N. Freed; N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. November 1996. Draft Standard. URL: https://tools.ietf.org/html/rfc2046
[RFC3986]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[permissions]
Mounir Lamouri; Marcos Caceres. The Permissions API. 7 April 2015. W3C Working Draft. URL: http://www.w3.org/TR/permissions/