Movatterモバイル変換

NDEF compatible tag types

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

In addition to that, theMIFARE Standard specifies a way for NDEF to work on top of the olderMIFARE Standard, which may be optionally supported by implementers.

A note about the NDEF mapping can be found here: MIFARE Classic as NFC Type MIFARE Classic Tag.

In addition to data types standardized forNDEF records by the NFC Forum, many commercial products such as bus cards, door openers may be based on theMIFARE Standard which requires specific NFC chips (same vendor of card and reader) in order to function.

The NDEF record and fields

AnNDEF record is a part of anNDEF message. Each record is a binary structure that contains a data payload, as well as associated type information. In addition to this, it includes information about how the data is structured, like payload size, whether the data is chunked over multiple records etc.

Only the first three bytes (lines in figure) are mandatory. First the header byte, followed by theTYPE LENGTH field andPAYLOAD LENGTH field, both of which may be zero.

TheIL field (bit `3`, id length) indicates whether anID LENGTH field is present. If theIL field is `0`, then theID field is not present either.

TheSR field (bit `4`, short record) indicates a short record, one with a payload length<= `255` bytes. Normal records can have payload lengths exceeding `255` bytes up to a maximum of `4` GB. Short records only use one byte to indicate length, whether as normal records use `4` bytes (`2`^`32``-1` bytes).

TheCF field (bit `5`, chunk flag) indicates whether the payload ischunked across multiple records.

Web NFC turns all received chunked records into logical records and transparently chunks sent payload when that is needed.

TheME field (bit `6`, message end) indicates whether this record is the last in theNDEF message.

TheMB field (bit `7`, message begin) indicates whether this record is the first of theNDEF message.

TheTYPE LENGTH field is an unsigned 8-bit integer that denotes the byte size of theTYPE field.

TheTYPE field is a globally unique and maintained identifier that describes the type of thePAYLOAD field in a structure, encoding and format dictated by value of theTNF field.

The [[[!NFC-RTD]]] requires that theTYPE field names MUST be compared in case-insensitive manner.

TheID LENGTH field is an unsigned 8-bit integer that denotes the byte size of theID field.

TheID field is an identifier in the form of a URI reference ([[RFC3986]]) that is unique, and can be absolute of relative (in the latter case the application must provide a base URI). Middle and terminating chunk records MUST NOT have anID field, other records MAY have it.

ThePAYLOAD LENGTH field denotes the byte size of thePAYLOAD field. If theSR field is `1`, its size is one byte, otherwise 4 bytes, representing an 8-bit or 32-bit unsigned integer, respectively.

ThePAYLOAD field carries the application bytes. Any internal structure of the data is opaque to NDEF. Note that in certain cases discussed later, this field MAY contain anNDEF message as data.

NDEF Record types

Reading anNFC tag

Reading anNFC tag containing anNDEF message, while the {{Document}} of thetop-level browsing context using Web NFC is visible. For instance, a web page instructs the user to tap an NFC tag, and then receives information from the tag.

Writing to anNFC tag

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

Making anNFC tag read-only

Note that making anNFC tag permanently read-only always involves a read operation.

Support for multiple NFC adapters

Users may attach one or more externalNFC adapters to their devices, in addition to a built-in adapter. Users may use eitherNFC adapter.

Feature support

Detecting if Web NFC is supported can be done by checking the {{NDEFReader}} object. Note that this does not guarantee that NFC hardware is available.

      if ("NDEFReader" in window) { /* Scan and write NDEF Tags */ }

General information about writing data

Writing data is generally straightforward, but there are a few gotcha's around how writing works with NFC.

An NFC reader works by polling, so in order to be able to write to a tag or making it permanently read-only, a tag first needs to be found and read, which means that polling needs to be initialized first.

If polling is not initiated already by first calling `scan()`, then the `write()` and `makeReadOnly()` methods will initiate it temporarily until a tag was found and read, and the operation was attempted.

This means that the flow is that first a read is performed as the tag is first found, then followed by a writing operation.

This means that if `scan()` is running and you have an event listener for the `reading` event, it will be dispatched once during a `write()` or `makeReadOnly()` operation, which might not be the intended behavior.

In the following sections we will discuss how you can easily deal with this behavior, but first a few simple examples.

Write a text string

Writing a text string to an NFC tag is straightforward.

      const ndef = new NDEFReader();      ndef.write(        "Hello World"      ).then(() => {        console.log("Message written.");      }).catch(error => {        console.log(`Write failed :-( try again: ${error}.`);      });

Write a URL

In order to write an NDEF record of URL type, simply use NDEFMessage. Here we rely on async/await.

      const ndef = new NDEFReader();      try {        await ndef.write({          records: [{ recordType: "url", data: "https://w3c.github.io/web-nfc/" }]        });      } catch {        console.log("Write failed :-( try again.");      };

Handling initial reads while writing

In order to write, a tag needs to be found and thus read. This gives you the ability to check whether it is actually a tag that you want to write to or not, by checking existing data or serial number.

For this reason, it is recommended calling `write()` from a `reading` event. Same applies to `makeReadOnly()`.

      const ndef = new NDEFReader();      let ignoreRead = false;      ndef.onreading = (event) => {        if (ignoreRead) {          return; // write pending, ignore read.        }        console.log("We read a tag, but not during pending write!");      };      function write(data) {        ignoreRead = true;        return new Promise((resolve, reject) => {          ndef.addEventListener("reading", event => {            // Check if we want to write to this tag, or reject.            ndef.write(data).then(resolve, reject).finally(() => ignoreRead = false);          }, { once: true });        });      }      await ndef.scan();      try {        await write("Hello World");        console.log("We wrote to a tag!")      } catch(err) {        console.error("Something went wrong", err);      }

Scheduling a write with a timeout

It can sometimes be useful to set a time limit on a write operation. Like you ask the user to touch a tag, and if no tag is found within a certain amount of time, then you time out.

      const ndef = new NDEFReader();      ndef.onreading = (event) => console.log("We read a tag!");      function write(data, { timeout } = {}) {        return new Promise((resolve, reject) => {          const ctlr = new AbortController();          ctlr.signal.onabort = () => reject("Time is up, bailing out!");          setTimeout(() => ctlr.abort(), timeout);          ndef.addEventListener("reading", event => {            ndef.write(data, { signal: ctlr.signal }).then(resolve, reject);          }, { once: true });        });      }      await ndef.scan();      try {        // Let's wait for 5 seconds only.        await write("Hello World", { timeout: 5_000 });      } catch(err) {        console.error("Something went wrong", err);      } finally {        console.log("We wrote to a tag!");      }

Handle scanning errors

This example shows what happens when {{NDEFReader/scan}} promise rejects and `readingerror` is fired.

      const ndef = new NDEFReader();      ndef.scan().then(() => {        console.log("Scan started successfully.");        ndef.onreadingerror = (event) => {          console.log("Error! Cannot read data from the NFC tag. Try a different one?");        };        ndef.onreading = (event) => {          console.log("NDEF message read.");        };      }).catch(error => {        console.log(`Error! Scan failed to start: ${error}.`);      });

Read a single tag, once

This example show you how to easily create a convenience function that just reads a single tag and then stops polling, saving battery life by cutting unneeded work.

The example could easily be extended to time out after a given amount of milliseconds.

      const ndef = new NDEFReader();      function read() {        return new Promise((resolve, reject) => {          const ctlr = new AbortController();          ctlr.signal.onabort = reject;          ndef.addEventListener("reading", event => {            ctlr.abort();            resolve(event);          }, { once: true });          ndef.scan({ signal: ctlr.signal }).catch(err => reject(err));        });      }      read().then(({ serialNumber }) => {        console.log(serialNumber);      });

Read data from tag, and write to empty ones

This example shows reading various different kinds of data which can be stored on a tag. If the tag is unformatted or contains an empty record, a text message is written with the value "Hello World".

      const ndef = new NDEFReader();      await ndef.scan();      ndef.onreading = async ({ message }) => {        if (message.records.length == 0 ||               // unformatted tag            message.records[0].recordType == "empty") {  // empty record          await ndef.write({            records: [{ recordType: "text", data: "Hello World" }]          });          return;        }        const decoder = new TextDecoder();        for (const record of message.records) {          switch (record.recordType) {            case "text":              const textDecoder = new TextDecoder(record.encoding);              console.log(`Text: ${textDecoder.decode(record.data)} (${record.lang})`);              break;            case "url":              console.log(`URL: ${decoder.decode(record.data)}`);              break;            case "mime":              if (record.mediaType === "application/json") {                console.log(`JSON: ${JSON.parse(decoder.decode(record.data))}`);              }              else if (record.mediaType.startsWith("image/")) {                const blob = new Blob([record.data], { type: record.mediaType });                const img = document.createElement("img");                img.src = URL.createObjectURL(blob);                img.onload = () => window.URL.revokeObjectURL(this.src);                document.body.appendChild(img);              }              else {                console.log(`Media not handled`);              }              break;            default:              console.log(`Record not handled`);          }        }      };

Save and restore game progress with an NFC tag

Filtering of relevant data sources can be done by the use of a custom record identifier, in this case "`/my-game-progress`". When we read the data, we immediately update the game progress by issuing a write with a custom NDEF data layout.

      const ndef = new NDEFReader();      await ndef.scan();      ndef.onreading = async ({ message }) => {        if (message.records[0]?.id !== "/my-game-progress")          return;        console.log(`Game state: ${ JSON.stringify(message.records) }`);        const encoder = new TextEncoder();        const newMessage = {          records: [{            id: "/my-game-progress",            recordType: "mime",            mediaType: "application/json",            data: encoder.encode(JSON.stringify({              level: 3,              points: 4500,              lives: 3            }))          }]        };        await ndef.write(newMessage);        console.log("Message written");      };

Write and read JSON (serialized and deserialized)

Storing and receiving JSON data is easy with serialization and deserialization.

      const ndef = new NDEFReader();      await ndef.scan();      ndef.onreading = (event) => {        const decoder = new TextDecoder();        for (const record of event.message.records) {          if (record.mediaType === "application/json") {            const json = JSON.parse(decoder.decode(record.data));            const article =/^[aeio]/i.test(json.title) ? "an" : "a";            console.log(`${json.name} is ${article} ${json.title}`);          }        }      };      const encoder = new TextEncoder();      await ndef.write({        records: [          {            recordType: "mime",            mediaType: "application/json",            data: encoder.encode(JSON.stringify({              name: "Benny Jensen",              title: "Banker"            }))          },          {            recordType: "mime",            mediaType: "application/json",            data: encoder.encode(JSON.stringify({              name: "Zoey Braun",              title: "Engineer"            }))          }]      });

Write data and print out existing data

Writing data requires tapping anNFC tag.

      const ndef = new NDEFReader();      await ndef.scan();      ndef.onreading = async (event) => {        const decoder = new TextDecoder();        for (const record of event.message.records) {          console.log("Record type:  " + record.recordType);          console.log("MIME type:    " + record.mediaType);          console.log("=== data ===\n" + decoder.decode(record.data));        }        try {          await ndef.write("Overriding data is fun!");        } catch(error) {          console.log(`Write failed :-( try again: ${error}.`);        }      };

Stop listening to NDEF messages

Read NDEF messages for 3 seconds by using {{NDEFScanOptions/signal}}.

      const ndef = new NDEFReader();      const ctrl = new AbortController();      await ndef.scan({ signal: ctrl.signal });      ndef.onreading = () => {        console.log("NDEF message read.");      };      ctrl.signal.onabort = () => {        console.log("We're done waiting for NDEF messages.");      };      // Stop listening to NDEF messages after 3s.      setTimeout(() => ctrl.abort(), 3_000);

Write a smart poster message

      const ndef = new NDEFReader();      const encoder = new TextEncoder();      await ndef.write({ records: [        {          recordType: "smart-poster",  // Sp          data: { records: [            {              recordType: "url",  // URL record for the Sp content              data: "https://my.org/content/19911"            },            {              recordType: "text",  // title record for the Sp content              data: "Funny dance"            },            {              recordType: ":t",  // type record, a local type to Sp              data: encoder.encode("image/gif") // MIME type of the Sp content            },            {              recordType: ":s",  // size record, a local type to Sp              data: new Uint32Array([4096]) // byte size of Sp content            },            {              recordType: ":act",  // action record, a local type to Sp              // do the action, in this case open in the browser              data: new Uint8Array([0])            },            {              recordType: "mime", // icon record, a MIME type record              mediaType: "image/png",              data: await (await fetch("icon1.png")).arrayBuffer()            },            {              recordType: "mime", // another icon record              mediaType: "image/jpg",              data: await (await fetch("icon2.jpg")).arrayBuffer()            }          ]}        }      ]});

Read an external record with an NDEF message as payload

External type records can be used to create application defined records. These records may contain anNDEF message as payload, with its ownNDEF records, includinglocal types that are used in the context of the application.

Note that thesmart poster record type also contains anNDEF message as payload.

As NDEF gives no guarantee on the ordering of records, using an external type record with anNDEF message as payload, can be useful for encapsulating related data.

This example shows how to read an external record for social posts, which contains anNDEF message, containing a text record and a record with thelocal type "act" (action), with definition borrowed fromsmart poster, but used in local application context.

      const ndef = new NDEFReader();      await ndef.scan();      ndef.onreading = (event) => {        const externalRecord = event.message.records.find(          record => record.type == "example.com:smart-poster"        );        let action, text;        for (const record of externalRecord.toRecords()) {          if (record.recordType == "text") {            const decoder = new TextDecoder(record.encoding);            text = decoder.decode(record.data);          } else if (record.recordType == ":act") {            action = record.data.getUint8(0);          }        }        switch (action) {          case 0: // do the action            console.log(`Post "${text}" to timeline`);            break;          case 1: // save for later            console.log(`Save "${text}" as a draft`);            break;          case 2: // open for editing            console.log(`Show editable post with "${text}"`);            break;        }      };

Write an external record with an NDEF message as payload

External type records can be used to create application defined records that may even contain anNDEF message as payload.

      const ndef = new NDEFReader();      await ndef.write({ records: [        {          recordType: "example.game:a",          data: {            records: [              {                recordType: "url",                data: "https://example.game/42"              },              {                recordType: "text",                data: "Game context given here"              },              {                recordType: "mime",                mediaType: "image/png",                data: getImageBytes(fromURL)              }            ]          }        }      ]});

Write and read unknown records inside an external record

Unknown type records may be useful inside external type records as developers know what they represent and therefore can avoid specifying the mime type.

      const encoder = new TextEncoder();      const ndef = new NDEFReader();      await ndef.write({ records: [        {          recordType: "example.com:shoppingItem", // External record          data: {            records: [              {                recordType: "unknown", // Shopping item name                data: encoder.encode("Food")              },              {                recordType: "unknown", // Shopping item description                data: encoder.encode("Provide nutritional support for an organism.")              }            ]          }        }      ]});

      const ndef = new NDEFReader();      await ndef.scan();      ndef.onreading = (event) => {        const shoppingItemRecord = event.message.records[0];        if (shoppingItemRecord?.recordType !== "example.com:shoppingItem")          return;        const [nameRecord, descriptionRecord] = shoppingItemRecord.toRecords();        const decoder = new TextDecoder();        console.log("Item name: " + decoder.decode(nameRecord.data));        console.log("Item description: " + decoder.decode(descriptionRecord.data));      };

Make an NFC tag permanently read-only

Making an NFC tag permanently read-only is straightforward.

      const ndef = new NDEFReader();      ndef.makeReadOnly().then(() => {        console.log("NFC tag has been made permanently read-only.");      }).catch(error => {        console.log(`Operation failed: ${error}`);      });

      const ndef = new NDEFReader();      try {        await ndef.write("Hello world");        console.log("Message written.");        await ndef.makeReadOnly();        console.log("NFC tag has been made permanently read-only after writing to it.");      } catch (error) {        console.log(`Operation failed: ${error}`);      }

TheNDEFMessage interface

The content of anyNDEF message is exposed by theNDEFMessage interface:

      [SecureContext, Exposed=Window]      interface NDEFMessage {        constructor(NDEFMessageInit messageInit);        readonly attribute FrozenArray<NDEFRecord> records;      };      dictionary NDEFMessageInit {        required sequence<NDEFRecordInit> records;      };

Therecords property represents alist ofNDEF records defining theNDEF message.

TheNDEFMessageInit dictionary is used to initialize anNDEF message.

TheNDEFRecord interface

The content of anyNDEF record is exposed by theNDEFRecord interface:

      [SecureContext, Exposed=Window]      interface NDEFRecord {        constructor(NDEFRecordInit recordInit);        readonly attribute USVString recordType;        readonly attribute USVString? mediaType;        readonly attribute USVString? id;        readonly attribute DataView? data;        readonly attribute USVString? encoding;        readonly attribute USVString? lang;        sequence<NDEFRecord>? toRecords();      };      dictionary NDEFRecordInit {        required USVString recordType;        USVString mediaType;        USVString id;        USVString encoding;        USVString lang;        any data; // DOMString or BufferSource or NDEFMessageInit      };

ThemediaType property represents theMIME type of theNDEF record payload.

TherecordType property represents theNDEF record types.

Theencoding attribute represents the [=encoding/name|encoding name=] used for encoding the payload in the case it is textual data.

Thelang attribute represents the [=language tag=] of the payload in the case that was encoded.

Alanguage tag is astring that matches the production of aLanguage-Tag defined in the [[BCP47]] specifications (see theIANA Language Subtag Registry for an authoritative list of possible values). That is, a language range is composed of one or moresubtags that are delimited by a U+002D HYPHEN-MINUS ("-"). For example, the 'en-AU' language range represents English as spoken in Australia, and 'fr-CA' represents French as spoken in Canada. Language tags that meet the validity criteria of [[RFC5646]] section 2.2.9 that can be verified without reference to the IANA Language Subtag Registry are considered structurally valid.

Thedata property represents thePAYLOAD field data.

ThetoRecords() method, when invoked, MUST return the result of runningconvert NDEFRecord.data bytes with theNDEF Record.

TheNDEFRecordInit dictionary is used to initialize anNDEF record with itsrecord typerecordType, and optionalrecord identifierid and payload datadata.

The mapping from data types of anNDEFRecordInit toNDEF record types is presented in the algorithmic steps which handle the data and described in the [[[#steps-receiving]]] and [[[#writing-content]]] sections.

Toconvert NDEFRecord.data bytes given a |record:NDEFRecord|, run these steps:

1. Let |bytes:byte sequence| be the value of record'sdata attribute.
2. Let |recordType:record type| be the value of |record|'srecordType attribute.
3. If the |recordType| value is "`smart-poster`", then return the result of runningparse records from bytes given |bytes| and `"smart-poster"`.
4. If runningvalidate external type on |recordType| returns true, then return the result of runningparse records from bytes given |bytes| and `"external"`.
5. Otherwise, [= exception/throw =] a {{"NotSupportedError"}}.

Therecord type string

This string defines the allowed record types for anNDEFRecord. The [[[#data-mapping]]] section describes how it is mapped toNDEF record types.

A standardizedwell known type name can be one of the following:

The "empty" string

The value representing anemptyNDEFRecord.

The "text" string

The value representing aText record.

The "url" string

The value representing aURI record.

The "smart-poster" string

The value representing aSmart poster record.

The "absolute-url" string

The value representing anabsolute-URL record.

The "mime" string

The value representing aMIME type record.

The "unknown" string

The value representing anunknown record.

In addition to [=well known type names=] it is also possible for organizations to create a customexternal type name, which is a string consisting of a [=domain=] name and a custom type name, separated by a colon `U+003A` (`:`).

Applications MAY also use alocal type name, which is a string that MUST start with lowercase character or a number, representing a type for an NFC Forum [=local type=]. It is typically used in a record of anNDEFMessage that is the payload of a parentNDEFRecord, for instance in asmart poster. The context of thelocal type is the parent record whose payload is theNDEFMessage to which this record belongs and thelocal type name SHOULD NOT conflict with any other type names used in that context.

Any implementation of Web NFC MUST transparently expose chunked records as single logical records, thereforeunchanged records are not explicitly represented.

Twowell-known type records (including any NFC Forumlocal type and any NFC Forumglobal type) MUST be compared character by character in case-sensitive manner.

Two external types MUST be compared character by character, in case-insensitive manner.

The binary representation of anywell-known type record andexternal type MUST be written as a relative URI (RFC 3986), omitting the namespace identifier (NID) "`nfc`" and namespace specific string (NSS) "`wkt`" and "`ext`", respectively, i.e. omitting the "`urn:nfc:wkt:`" and "`urn:nfc:ext:`" prefixes. For instance, "`urn:nfc:ext:company.com:a" is stored as "`company.com:a`" and thewell-known type records of aText record is "`urn:nfc:wkt:T`", but it is stored as "`T`".

Data mapping

The mapping from data types of anNDEFRecordInit toNDEF record types, as used in the [[[#writing-content]]] section is as follows:

* A [=local type=] record has to be embedded with theNDEFMessage payload of another record.

The mapping fromNDEF record types toNDEFRecord, as used for incomingNDEF messages described in the [[[#steps-receiving]]] section, is as follows.

NFC state associated with the settings object

Therelevant settings object of theactive document of abrowsing context which supports NFC has an associatedNFC state record with the followinginternal slots:

Theactivated reader objects is the value of the[[\ActivatedReaderList]] internal slot.

Thepending write tuple is the value of the[[\PendingWrite]] internal slot.

Thepending makeReadOnly tuple is the value of the[[\PendingMakeReadOnly]] internal slot.

NFC is suspended if the[[\Suspended]] internal slot is true.

Tosuspend NFC, set the[[\Suspended]] internal slot to true.

Toresume NFC, set the[[\Suspended]] internal slot to false.

Internal slots are used only as a notation in this specification, and implementations do not necessarily have to map them to explicit internal properties.

Handling NFC adapters

Obtaining permission

The Web NFC API is a [=default powerful feature=] which is identified by the [=powerful feature/name=] "nfc".

Handling visibility change

The [=page visibility change steps=] for this specification, given the string |visibilityState| and the {{Document}} |document|, are:

1. If |visibilityState| is `"visible"`,resume NFC and abort these steps.
2. Otherwise, perform these steps:
   1. Suspend NFC.
   2. Attempt toabort a pending write operation.
   3. Attempt toabort a pending make read-only operation.

The termsuspended refers to NFC operations being suspended, which means that noNFC content is written byNDEFReaders, and no receivedNFC content is presented to any {{NDEFReader}} while being suspended.

Aborting pending write operation

Aborting pending make read-only operation

Releasing NFC

Torelease NFC on anenvironment settings object, perform the following steps:

1. Suspend NFC.
2. Attempt toabort a pending write operation.
3. Attempt toabort a pending make read-only operation.
4. Clear theactivated reader objects.
5. Release the NFC resources on the underlying platform.

The UA mustrelease NFC given the document'srelevant settings object as additionalunloading document cleanup steps.

TheNDEFWriteOptions dictionary

      dictionary NDEFWriteOptions {        boolean overwrite = true;        AbortSignal? signal;      };

When the value of theoverwrite property is false, thewrite algorithm will read theNFC tag to determine if it hasNDEF records on it, and if yes, it will not execute any pending write.

Thesignal property allows to abort the {{NDEFReader/write()}} operation.

TheNDEFMakeReadOnlyOptions dictionary

      dictionary NDEFMakeReadOnlyOptions {        AbortSignal? signal;      };

Thesignal property allows to abort the {{NDEFReader/makeReadOnly()}} operation.

TheNDEFScanOptions dictionary

        dictionary NDEFScanOptions {          AbortSignal signal;        };

Thesignal property allows to abort the {{NDEFReader/scan()}} operation.

Writing content

This section describes how to write anNDEF message to anNFC tag when it is next time in proximity range before a timer expires. At any time there is a maximum of oneNDEF message that can be set for writing for anorigin until the current message is sent or the write is aborted.

Creating NDEF message

Making content read-only

This section describes how to make anNFC tag permanently read-only when it is in proximity range. At any time there is a maximum of one request for anorigin until theNFC tag is made permanently read-only or the operation is aborted.

Listening for content

To listen forNFC content, the client MUST activate an {{NDEFReader}} instance by callingNDEFReader.scan(). When attaching an event listener for the "`reading`" event on it,NFC content is accessible to the client.

If there are any {{NDEFReader}} instances inactivated reader objects then theUA MUST listen toNDEF messages on all connected NFC adapters.

Parsing content

Chain of trust

Implementations need to make sure that when the user authorizes a method which is part of the Web NFC API, only that action is run, without side effects.

By default, NDEF doesn't provide any way to make the content trusted beyond allowing tags to be made permanently read-only after writing data to them. This can even be done from a factory setting.

Data written by the use of this API is not signed or encrypted automatically, which follows existing native NFC APIs. In order to protect the integrity and authenticity of NDEF messages, the NFC Forum introduced [[NDEF-SIGNATURE]]. UsingNDEF signature and key management is the responsibility of the application.

For trusting theconfidentiality of the data exchanged via NFC, applications may use encryptedNFC content.

For trusting theintegrity of the data exchanged via NFC, applications may use anNDEF signature, with key management based on Public Key Infrastructure (PKI).

Security considerations for MIME types in general are discussed in [[RFC2048]] and [[RFC2046]].

Privacy implications and implementation considerations

The comparison to barcodes or QR codes is appropriate because NFC tags are another non-human-readable method of exchanging data and sharing them can have unforeseen privacy and security implications. For a web site to read a QR code, a piece of interruptive UI must be used (the camera) which captures an image and makes it apparent that the contents of this image (including the QR code) will be available to the web page, making it clear to the user that scanning is being performed.

Scanning a tag with NFC requires the user to place the scanning device (e.g. phone) in close proximity to the NFC tag - usually 5-10 cm, 2-4 inches.

Scanning a tag when a Web NFC scan is not active, triggers the host OS handling. Thus launching URLs and apps from scanning a NFC tag is not handled and supported by Web NFC itself.

Furthermore, Web NFC scanning needs to be activated from a user interaction, and scanning is paused when the web site is not in focus or the device screen turns off (i.e. is not unlocked). This is put in place so that accidental scans are not likely to happen.

Web NFC further recommends that the implementation makes it very clear UX-wise to the user that data will be scanned when placing the scanning device in close proximity to a NFC tag - basically mimicking the UX flow of scanning a QR code.

There are many options for doing so, like playing back a sound or showing some persistent UI while the scanning can happen, for instance a modal dialog with the ability to cancel at any point.

An implementation could also show the data that is about to be uploaded, postpone sharing the read data until the user OK'd it and even show some UI allowing the user to select which records to share.

Things that users should be made aware of when using NFC

This section details some of the things that users ought to be aware of when using NFC. It is recommendated that implementations help educate the users of given facts before or when related NFC actions are performed.

Data that is read is shared with site

When a site has access to read NFC content, then the data of the scanned tags is shared with the site, in a similar way to uploading files and images. As with any site, it is up to the user whether to trust that the site handles this data properly and in the intended manner.

A site may modify and overwrite data of tags that are not made read-only

Deployed NFC solutions, like tags in stores etc, should always be made read-only in order to ensure they are not modified by mistake or as part of a malicious act.

Private tags and stickers are often unlocked (writable) from the factory and the user should be aware that such tags might be overwritten/modified by scanning them.

Reading a fixed (e.g. mounted) tag may expose reading location

A fixed tag may encode its ID or location in the data, meaning that reading it exposes that information to the site that knows the physical location of the tag, which then can deduct the location the read took place. That combined with being logged into a service, can share your location data with the site.

Data written is readable by other apps and sites with granted read access Any NDEF data on a tag can be read by any app or web site with the proper access, so if that is not intended then the data should be encrypted in a secure manner that only who is supposed to read it can.

Multiple tags may be within the reading field at the same time

NFC can only read one tag at the time, but multiple tags can be detected and one of the tags can be selected as the tag to communicate with.

Use cases for this could be having multiple smart cards (NFC based) in your wallet and not wanting to take the card out.

This is mostly useful for payment cards and travel cards that are read by external hardware and thus not a use-case for Web NFC. For Web NFC, we do not allow reading when there are multiple tags available, preventing the following attack vector.

There is an attack vector, where someone places another malicious NFC tag/sticker on top of a legitimate tag, in order to load the wrong app/site, or inject wrong data into the right app/site. They can do so by cloning the data of the original tag and modifying it - either by changing the URL to load a malicious app/site, or by changing the data to inject malicious data in the right app/site. Example: the tag is supposed to take you tohttps://example.com but is modified to take you tohttps://exаmple.com (that is with a Cyrillic а) - it looks legitimate and you might now to giving sensitive data to a malicious site.

Loading web sites from a tag is outside the scope of Web NFC, but it is recommended for user agents to not auto load URLs when multiple tags are available due to the above attack vector.

By disallowing reading when there are multiple tags available, Web NFC protects well against injecting wrong/malicious data into a site as shielding the existing NFC tag is quite difficult as it requires ferrite shielding which is quite visible. Metal interferes with the magnetic field and makes tags not readable.

Assets

Attacker model

The following attacker patterns have been considered:

• Malicious web page creator: phishing user data, identity or other privacy sensitive attributes, destroying or modifying NFC tags to cause further damage through fake identities and attack vectors.
• Malicious NFC tag creator: same as above, but with the additional possibility to create, delete or modify the NFC tags locally. As a result can compromise integrity of user device, cause data injection, redirect to malicious web page, phishing user location, causing side actions such as installing applications, trigger automated dispatching or other actions.
• Compromised device or user agent: man-in-the-middle (MITM) attack: any MITM style attack between Web NFC implementation and anNFC adapter in a user device, including attempts to interact with a web site using Web NFC by presenting modified or replayed NDEF records.

Threats

An introduction to NFC security is foundhere. Potential threats for Web NFC are given below.

Security mechanisms for implementations

Security mechanisms for applications

Security policies

This section lists the normative security policies for implementations.