Repository navigation
Expand file tree
/
Copy pathindex.html
More file actions
5225 lines (5066 loc) · 189 KB
/
Copy pathindex.html
File metadata and controls
5225 lines (5066 loc) · 189 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>Web NFC</title>
<meta charset="UTF-8">
<link rel="icon" type="image/png" href="images/webnfc-favicon-simple.png">
<script type="module" src="ndef-record.js"></script>
<script src='https://www.w3.org/Tools/respec/respec-w3c' async class=
'remove'></script>
<script class="remove">
var respecConfig = {
shortName: "web-nfc",
group: "cg/web-nfc",
specStatus: "CG-DRAFT",
editors: [
{
name: "Kenneth Rohde Christiansen",
company: "Intel",
companyURL: "https://intel.com/",
},
{
name: "François Beaufort",
company: "Google LLC",
companyURL: "https://google.com/"
},
],
formerEditors: [
{
name: "Zoltan Kis",
company: "Intel",
companyURL: "https://intel.com/"
},
{
name: "Alexander Shalamov",
company: "Intel",
companyURL: "https://intel.com/",
},
],
logos: [
{
src: 'images/webnfc-logo.svg',
url: "https://w3c-cg.github.io/web-nfc/",
alt: "Web NFC logo",
width: 95,
height: 68,
id: 'webnfc-logo'
}
],
latestVersion: "https://w3c-cg.github.io/web-nfc/",
testSuiteURI: "https://wpt.fyi/web-nfc/",
github: "w3c-cg/web-nfc",
xref: "web-platform",
localBiblio: {
"NFC-SECURITY": {
href: "https://w3c-cg.github.io/web-nfc/archive/security-privacy.html",
title: "Web NFC Security and Privacy",
publisher: "W3C",
date: "25 April 2015",
},
"NFC-USECASES": {
href: "https://w3c-cg.github.io/web-nfc/use-cases.html",
title: "Web NFC Use Cases",
publisher: "W3C",
date: "25 April 2015",
},
"NFC-STANDARDS": {
href: "http://members.nfc-forum.org/specs/spec_list/",
title: "NFC Forum Technical Specifications",
publisher: "NFC Forum",
date: "24 July 2006",
},
"NFC-NDEF": {
href: "http://members.nfc-forum.org/specs/spec_list/",
title: "NFC Data Exchange Format (NDEF) Technical Specification",
publisher: "NFC Forum",
date: "24 July 2006",
},
"NFC-RTD": {
href: "http://members.nfc-forum.org/specs/spec_list/",
title: "NFC Record Type Definition (RTD) Technical Specification",
publisher: "NFC Forum",
date: "24 July 2006",
},
"NDEF-TEXT": {
href: "http://members.nfc-forum.org/specs/spec_list/",
title: "NFC Forum Text Record Type Definition",
publisher: "NFC Forum",
date: "14 August 2013",
},
"NDEF-URI": {
href: "http://members.nfc-forum.org/specs/spec_list/",
title: "NFC Forum URI Record Type Definition",
publisher: "NFC Forum",
date: "24 July 2006",
},
"NDEF-SMARTPOSTER": {
href: "http://members.nfc-forum.org/specs/spec_list/",
title: "NFC Forum Smart Poster Record Type Definition",
publisher: "NFC Forum",
date: "24 July 2006",
},
"NDEF-SIGNATURE": {
href: "http://members.nfc-forum.org/specs/spec_list/",
title: "NFC Forum Signature Record Type Definition",
publisher: "NFC Forum",
date: "18 November 2010",
},
"NFC-HANDOVER": {
href: "http://members.nfc-forum.org/specs/spec_list/",
title: "NFC Forum Connection Handover Technical Specification",
publisher: "NFC Forum",
date: "16 January 2014",
},
"ISO-639.2": {
href: "https://www.loc.gov/standards/iso639-2/php/code_list.php",
title: "Codes for the Representation of Names of Languages",
publisher: "ISO",
date: "18 March 2014",
},
},
lint: { "no-unused-dfns": false },
};
</script>
<style>
table.simple { border: 1px solid #000; }
table.simple td { border-right: 1px solid #000; }
img.illustration { width: 100%; height: auto }
body { background-repeat: no-repeat !important; }
</style>
</head>
<body data-cite="MIMESNIFF SECURE-CONTEXTS PERMISSIONS ENCODING">
<!-- - - - - - - - - - - - - - - - Abstract - - - - - - - - - - - - - - - - -->
<section id="abstract">
<p>
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.
</p>
<p>
The hardware standard is defined in [[[NFC-STANDARDS]]].
</p>
<p>
This document defines an API to enable selected use cases based on
NFC technology. The current scope of this specification is <a>NDEF</a>.
</p>
<p class="advisement">
Low-level I/O operations (e.g. ISO-DEP, NFC-A/B, NFC-F) and Host-based Card
Emulation (HCE) are <b>not</b> supported within the current scope.
</p>
</section>
<!-- - - - - - - - - - - - Status of this document - - - - - - - - - - - - -->
<section id="sotd">
<p>
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.
</p>
</section>
<!-- - - - - - - - - - - - - - - Conformance - - - - - - - - - - - - - - - -->
<section id="conformance">
<p>
This document defines conformance criteria that apply to a single
product: the <dfn>UA</dfn> (user agent) that implements the interfaces it
contains.
</p>
</section>
<!-- - - - - - - - - - - - - - - Introduction - - - - - - - - - - - - - - -->
<section class="informative"> <h2>Introduction</h2>
<p>
Web NFC user scenario is as follows: Hold a device in close proximity to a
passively powered NFC tag, such as a plastic card or sticker, in order to
read and/or write data.
</p>
<p>
NFC works using magnetic induction, meaning that the reader (an active,
powered device) 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.
</p>
<p>
As NFC is based on existing RFID standards, many NFC chipsets support
reading RFID tags, but some of these are only supported by single
vendors and not part of the NFC standards. As such, this document
specifies ways to interact with the NFC Data Exchange Format (NDEF).
</p>
</section> <!-- Introduction -->
<!-- - - - - - - - - - - - - - - Terminology - - - - - - - - - - - - - - - -->
<section> <h2>Terminology and conventions</h2>
<p>
The Augmented Backus-Naur Form (ABNF) notation used is specified in
[[RFC5234]].
</p>
<p>
<b>NFC</b> stands for Near Field Communications, a 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 <a href="https://www.nfc-forum.org/specs/spec_list/">
NFC Forum Technical Specifications</a> for a complete
listing.
</p>
<p>
An <dfn>NFC adapter</dfn> 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 or more attached via USB.
</p>
<div>
An <dfn>NFC tag</dfn> is a passive NFC device that is not <a>blocklisted</a>.
The <a>NFC tag</a> is powered by magnetic induction when an active NFC
device is in proximity range. An <a>NFC tag</a> that supports <a>NDEF</a>
contains a single <a>NDEF message</a>.
<p class="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. They may also expose an <a>NDEF</a> message.
</p>
</div>
<div>
An <dfn>NFC peer</dfn> is an active, powered device which can interact
with other devices in order to exchange data using NFC.
<p class="issue" data-number="529">
As currently spec'ed, peer-to-peer is not supported.
</p>
</div>
<p>
An <dfn>NFC device</dfn> is either an <a>NFC peer</a>, or an <a>NFC tag</a>.
</p>
<p>
<dfn>NDEF</dfn> is an abbreviation for NFC Forum Data Exchange Format, a
lightweight binary message format that is standardized in [[!NFC-NDEF]].
</p>
<p>
An <dfn>NDEF message</dfn> encapsulates one or more application-defined
<a>NDEF record</a>s. NDEF messages can be stored on an <a>NFC tag</a> or
exchanged between NFC-enabled devices.
</p>
<p>
The term <dfn>NFC content</dfn> denotes all bytes sent to or received from
an <a>NFC tag</a>. In the current API it is synonym to <a>NDEF message</a>.
</p>
</section> <!-- Terminology -->
<section class="informative">
<h2>The NFC Standard</h2>
<p>
NFC is standardized in the NFC Forum and described in [[NFC-STANDARDS]].
</p>
<section class="informative"> <h3>NDEF compatible tag types</h3>
<p>
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.
</p>
<p>
In addition to that, the <a>MIFARE Standard</a> specifies a way
for NDEF to work on top of the older <a>MIFARE Standard</a>, which may
be optionally supported by implementers.
</p>
<p>
A note about the NDEF mapping can be found here:
<a href="https://www.nxp.com/docs/en/application-note/AN1305.pdf">
MIFARE Classic as NFC Type MIFARE Classic Tag</a>.
</p>
<div>
<ol>
<li>
<dfn>NFC Forum Type 1</dfn>: This tag is 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 `96` bytes and
`2` Kbytes. Communication speed is `106` kbit/s. In contrast to all other
types, these tags have no anti-collision protection for dealing with multiple
tags within the NFC field.
</li>
<li>
<dfn>NFC Forum Type 2</dfn>: This tag is 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/s.
</li>
<li>
<dfn>NFC Forum Type 3</dfn>: This tag is based on the Japanese Industrial
Standard (JIS) X 6319-4 (ISO/IEC 18092), commonly known as FeliCa. The tags are
preconfigured to be either rewritable or read-only. Memory is `2` kbytes.
Communication speed is `212` kbit/s or `424` kbit/s.
</li>
<li>
<dfn>NFC Forum Type 4</dfn>: This tag is based on the ISO/IEC 14443-4 A/B
(NFC A, NFC B) and thus supports either NFC-A or NFC-B
for communication. On top of that the tag may optionally support ISO-DEP
(Data Exchange Protocol defined in ISO/IEC 14443 (ISO/IEC 14443-4:2008
Part 4: Transmission protocol). The tags are preconfigured
to be either rewritable or read-only. Variable memory, up to `32` kbytes.
Supports three different communication speeds `106` or `212` or
`424` kbit/s.
</li>
<li>
<dfn>NFC Forum Type 5</dfn>: This tag is based on ISO/IEC 15693 (NFC-V) and
allows reading and writing an NDEF message on an ISO/IEC 15693 RF tag
that is accessible by long range RFID readers as well. The NFC communication
is limited to short distance and may use the <i>Active Communication Mode</i> of
ISO/IEC 18092 where the sending peer generates the field which balances
power consumption and improves link stability. Variable memory, up to `64` kbytes.
Communication speed is `26.48` kbit/s.
</li>
<li>
<dfn>MIFARE Standard</dfn>: This tag, often sold under the brand names MIFARE
Classic or MIFARE Mini, 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 `320` and `4` kbytes. Communication speed is `106` kbit/s.
<p class="note">
<a>MIFARE Standard</a> is not an NFC Forum type and can only be read by devices
using NXP hardware. Support for reading and writing to tags based on the
<a>MIFARE Standard</a> is thus non-nominative, but the type is included
due to the popularity and use in legacy systems.
</p>
</li>
</ol>
</div>
<p>
In addition to data types standardized for <a>NDEF record</a>s by the NFC
Forum, many commercial products such as bus cards, door openers may be based
on the <a>MIFARE Standard</a> which requires specific NFC chips (same vendor of
card and reader) in order to function.
</p>
</section>
<section>
<h3>
The NDEF record and fields
</h3>
<p>
An <dfn>NDEF record</dfn> is a part of an <a>NDEF message</a>. 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.
</p>
<div>
A generic record looks like the following:
<ndef-record class="ndef"
header="*,*,*,*,*,*"
content="*,PAYLOAD LENGTH - 1 (SR) to 4 bytes,ID LENGTH (optional),TYPE (optional),ID (optional),PAYLOAD (optional)">
</ndef-record>
</div>
<p>
Only the first three bytes (lines in figure) are mandatory. First the
header byte, followed by the <a>TYPE LENGTH field</a> and <a>PAYLOAD
LENGTH field</a>, both of which may be zero.
</p>
<div>
The <dfn>TNF field</dfn> (bit `0-2`, type name format) indicates the format
of the type name and is often exposed by native NFC software stacks. The
field can take binary values denoting the following NDEF record payload types:
<table class="simple">
<tr>
<th><strong>TNF value</strong></th>
<th><strong>Description</strong></th>
</tr>
<tr>
<td>0</td>
<td><a>Empty record</a></td>
</tr>
<tr>
<td>1</td>
<td>NFC Forum [=well-known type record=]</td>
</tr>
<tr>
<td>2</td>
<td><a>MIME type record</a></td>
</tr>
<tr>
<td>3</td>
<td><a>Absolute-URL record</a></td>
</tr>
<tr>
<td>4</td>
<td>NFC Forum <a>external type record</a></td>
</tr>
<tr>
<td>5</td>
<td><a>Unknown record</a></td>
</tr>
<tr>
<td>6</td>
<td><a>Unchanged record</a></td>
</tr>
<tr>
<td>7</td>
<td>Reserved for future use</td>
</tr>
</table>
</div>
<p>
The <dfn>IL field</dfn> (bit `3`, id length) indicates whether an
<a>ID LENGTH field</a> is present. If the <a>IL field</a> is `0`, then the
<a>ID field</a> is not present either.
</p>
<p>
The <dfn>SR field</dfn> (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`<sup>`32`</sup>`-1` bytes).
</p>
<p>
The <dfn>CF field</dfn> (bit `5`, chunk flag) indicates whether the payload
is <a>chunked</a> across multiple records.
</p>
<p class="note">
Web NFC turns all received chunked records into logical records and
transparently chunks sent payload when that is needed.
</p>
<p>
The <dfn>ME field</dfn> (bit `6`, message end) indicates whether this record
is the last in the <a>NDEF message</a>.
</p>
<p>
The <dfn>MB field</dfn> (bit `7`, message begin) indicates whether this
record is the first of the <a>NDEF message</a>.
</p>
<p>
The <dfn>TYPE LENGTH field</dfn> is an unsigned 8-bit integer that denotes
the byte size of the <a>TYPE field</a>.
</p>
<p>
The <dfn>TYPE field</dfn> is a globally unique and maintained identifier
that describes the type of the <a>PAYLOAD field</a> in a structure,
encoding and format dictated by value of the <a>TNF field</a>.
</p>
<p class="note">
The [[[!NFC-RTD]]] requires that the <a>TYPE field</a> names MUST be
compared in case-insensitive manner.
</p>
<p>
The <dfn>ID LENGTH field</dfn> is an unsigned 8-bit integer that denotes
the byte size of the <a>ID field</a>.
</p>
<p>
The <dfn>ID field</dfn> 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 an <a>ID field</a>, other records MAY have it.
</p>
<p>
The <dfn>PAYLOAD LENGTH field</dfn> denotes the byte size of the
<a>PAYLOAD field</a>. If the <a>SR field</a> is `1`, its size is one byte,
otherwise 4 bytes, representing an 8-bit or 32-bit unsigned integer,
respectively.
</p>
<p>
The <dfn>PAYLOAD field</dfn> 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 an <a>NDEF message</a> as data.
</p>
</section>
<section>
<h3>
NDEF Record types
</h3>
<section> <h4>Empty NDEF record (TNF 0)</h4>
<p>
An <dfn>empty record</dfn>'s' <a>TYPE LENGTH field</a>,
<a>ID LENGTH field</a> and <a>PAYLOAD LENGTH field</a> MUST be `0`, thus
the <a>TYPE field</a>, <a>ID field</a> and <a>PAYLOAD field</a> MUST NOT
be present.
</p>
<ndef-record
header="1,1,0,1,0,0 (EMPTY)"
content="0,0,_,_,_,_"
short>
</ndef-record>
</section>
<section>
<h4>
Well-known type records (TNF 1)
</h4>
<p>
The NFC Forum has standardized a small set of useful sub record types in
[[NFC-RTD]] (Resource Type Definition specifications) called
<dfn>well-known type record</dfn>s, for instance text, URL, media and others.
In addition, there are record types designed for more
complex interactions, such as smart posters (containing optional embedded
records for url, text, signature and actions), and handover records.
</p>
<p>
The type information stored in the <a>TYPE field</a> of
<a>well-known type records</a> can be of two kinds:
<a href="#well-known-local-types">local types</a>
and <a href="#well-known-global-types">global types</a>.
</p>
<section><h4>Well-known local types</h4>
<p>
NFC Forum <dfn>local type</dfn> that are defined by the NFC Forum or
by an application, and always start with lowercase character or a
number. Those are usually short strings that are unique only within
the local context of the containing record. They are used when the
meaning of the types doesn't matter outside of the local context of the
containing record and when storage usage is a hard constraint. See
<a>Smart poster</a> for an example on how local types are used.
</p>
<p class="note">
A [=local type=] is thus defined in terms of a containing record type,
and thus doesn't need any namespacing. For this reason the same local
type name can be used within another record type with different meaning
and different payload type.
</p>
</section>
</section> <!-- Well-known (TNF 1) types -->
<section><h4>Well-known global types</h4>
<p>
NFC Forum <dfn>global type</dfn>s are defined and managed by the
NFC Forum and usually start with an uppercase character.
Examples: "`T`" for text, "`U`" for URL, "`Sp`" for smart poster,
"`Sig`" for signature, "`Hc`" for handover carrier, "`Hr`" for
handover request, "`Hs`" for handover select, etc.
</p>
<section> <h5>Text record</h5>
<div>
The <dfn>Text record</dfn> is a [=well-known type record=] that is defined
in the [[NDEF-TEXT]] specification.
The <a>TNF field</a> is `1` and the <a>TYPE field</a> is "`T`" (`0x54`).
The first byte of the <a>PAYLOAD field</a> is a status byte, followed
by the [=language tag=] in US-ASCII encoding.
The rest of the payload is the actual text, encoded either in UTF-8 or
UTF-16, as indicated by the status byte as follows:
<ul>
<li>Bits 0 to 5 define the length of the [=language tag=].</li>
<li>Bit 6 is `0`.</li>
<li>
If bit 7 is `0`, means the payload is encoded in UTF-8, otherwise
if bit 7 is `1` the payload is encoded in UTF-16.
</li>
</ul>
</div>
</section>
<section> <h5>URI record</h5>
<p>
<dfn>URI record</dfn> is defined in [[NDEF-URI]].
The <a>TNF field</a> is `1` and the <a>TYPE field</a> is "`U`" (`0x55`).
The first byte of the <a>PAYLOAD field</a> is a URI identifier code,
in fact an index in an abbreviation table where the values are prepended
to the rest of the URI. For instance the value `0` denotes no prepending,
`1` denotes "`http://www.`", `0x04` denotes "`https://`"" and so on.
The rest of the payload contains the rest of the URI as a UTF-8 string
(and if the first byte is `0`, then it denotes the whole URI).
</p>
<p>
The URI is defined in [[RFC3987]] and in fact is a UTF-8 encoded IRI
that can be a URN or a URL.
</p>
</section>
<section> <h5>Smart poster record</h5>
<div>
<dfn>Smart poster</dfn> is defined in [[NDEF-SMARTPOSTER]] to describe a
given web content as an NDEF record that contains an <a>NDEF message</a>
as payload, including the following records:
<ul>
<li>
A single mandatory <a>URI record</a> that refers to the
<a>smart poster</a> content.
<p class="note">
The [[NDEF-SMARTPOSTER]] states that applications SHALL use only the
<a>smart poster</a> record if it is present in an <a>NDEF message</a>
that also contains other <a>URI records</a>.
</p>
</li>
<li>
Zero or more <a>Text records</a> that act as a <dfn>title record</dfn>
related to the content. When there are more than one title record
present, they MUST be with different <a>language tags</a>.
Applications SHOULD select one <a>title record</a> for presentation
to the end user.
</li>
<li>
Zero or more <a>MIME type records</a> that act as <dfn>icon record</dfn>
related to the content. The <a>MIME type</a> is usually "`image/jpg`",
"`image/png`", "`image/gif`", or even "`video/mpeg`".
Applications SHOULD select one <a>icon record</a> for presentation
to the end user.
</li>
<li>
One optional <dfn>type record</dfn> that has a [=local type name=]
"`t`" specific to <a>smart poster</a> and the <a>PAYLOAD field</a>
contains a UTF-8 encoded MIME type for the content referred to by the
<a>URI record</a>.
</li>
<li>
One optional <dfn>size record</dfn> that has [=local type name=] "`s`"
specific to <a>smart poster</a> and the <a>PAYLOAD field</a> contains
a 4-byte 32 bit unsigned integer that denotes the size of the object
referred to by the URL in the <a>URI record</a> of the
<a>smart poster</a>.
</li>
<li>
One optional <dfn>action record</dfn> that has a [=local type name=]
"`act`" specific to <a>smart poster</a> and the <a>PAYLOAD field</a>
contains a single byte, whose value has the following meaning:
<table class="simple">
<tr>
<th><strong>Value</strong></th>
<th><strong>Description</strong></th>
</tr>
<tr>
<td>0</td>
<td>Do the action</td>
</tr>
<tr>
<td>1</td>
<td>Save for later</td>
</tr>
<tr>
<td>2</td>
<td>Open for editing</td>
</tr>
<tr>
<td>3..0xFF</td>
<td>Reserved for future use</td>
</tr>
</table>
There is no default action on the <a>smart poster</a> content if the
<a>action record</a> is missing.
<p class="note">
At the time of NDEF standardization the value `0` ("do the action") was
intended for use cases like send an SMS, make a call or launch browser.
Similarly, the value `1`, ("save the content for later processing") was
intended for use cases like store the SMS in inbox, save the URL in
bookmarks, or save the phone number to contacts. Also, the value `2`
("open for editing") was meant to open the smart poster content with a
default application for editing.
</p>
<p>
Implementations don't need to implement any standardized behavior for the
actions defined here. In this API it's up to the applications what actions
they define (that may include the use cases above). However, Web NFC
just provides the values.
</p>
</li>
<li>
A <a>smart poster</a> MAY also contain other records, which can be
handled in an application specific manner.
</li>
</ul>
</div>
<div>
The example below shows a smart poster record that embeds a text and a
URL record.
<ndef-record
header="1,1,0,1,0,1 (WELL KNOWN)"
content="*,*,_,'Sp' (0x53 0x70),_,*"
short>
<ndef-record slot="payload"
header="1,0,0,1,0,1 (WELL KNOWN)"
content="TYPE LENGTH (1 byte),*,_,'T' (0x54),_,*"
short noindices>
</ndef-record>
<ndef-record slot="payload"
header="0,1,0,1,0,1 (WELL KNOWN)"
content="TYPE LENGTH (1 byte),*,_,'U' (0x55),_,*"
short noindices>
</ndef-record>
</ndef-record>
</div>
</section>
<section> <h5>Signature records</h5>
<p>
<dfn>NDEF Signature</dfn> is defined [[NDEF-SIGNATURE]].
Its <a>TYPE field</a> contains "`Sig`" (`0x53`, `0x69`, `0x67`) and its
<a>PAYLOAD field</a> contains version, signature and a certificate chain.
</p>
<p class="issue" data-number="363">
As currently spec'ed, this is not supported.
</p>
</section>
<section> <h5>Handover records</h5>
<p>
<dfn>NFC handover</dfn> is defined [[NFC-HANDOVER]] 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.
</p>
<p class="issue" data-number="364">
As currently spec'ed, this is not supported.
</p>
</section>
</section> <!-- well-known global types -->
<section>
<h4>
MIME type records (TNF 2)
</h4>
<div>
The <dfn>MIME type record</dfn>s are records that store binary
data with associated <a>MIME type</a>.
<ndef-record
header="*,*,*,*,*,2 (MIME)"
content="*,*,*,SERIALIZED MIME TYPE,*,MIME TYPE PAYLOAD"
short>
</ndef-record>
</div>
</section>
<section>
<h4>
Absolute-URL records (TNF 3)
</h4>
<p>
In <dfn>absolute-URL record</dfn>s the <a>TYPE field</a> contains the
<a>absolute-URL string</a>, and not the payload.
</p>
<p class=note>
NOTE: Some platforms, like Windows Phone have stored additional data
in the payload, but any payload data in these records are ignored by
other platforms such as Android. On Android, reading such a record,
will attempt to load the URL in Chrome and it is as such not intended
for client applications.
</p>
<div>
<ndef-record
header="*,*,*,*,*,3 (ABSOLUTE URL)"
content="*,*,*,ABSOLUTE URL STRING,*,PAYLOAD (optional/ignored)"
short>
</ndef-record>
</div>
</section>
<section>
<h4>
External type records (TNF 4)
</h4>
<p>
The NFC Forum <dfn data-no-export="">external type record</dfn>s are for
application specified data types and are defined in [[[NFC-RTD]]].
</p>
<p>
The <dfn>external type</dfn> is a URN with the prefix `"urn:nfc:ext:"` followed by
the name of the owner [=domain=], adding a `U+003A` (`:`), then a non-zero
type name, for instance `"urn:nfc:ext:w3.org:atype"`, stored as
`"w3.org:atype"` in the <a>TYPE field</a>.
</p>
<div>
<ndef-record
header="*,*,*,*,*,4 (EXTERNAL)"
content="*,*,*,EXTERNAL TYPE (eg. w3.org:member),*,*"
short>
</ndef-record>
</div>
</section>
<section>
<h4>
Unknown type records (TNF 5)
</h4>
<p>
The <dfn>unknown record</dfn>s are records that store
opaque data without associated <a>MIME type</a>, meaning that the
`application/octet-stream` default <a>MIME type</a> MAY be assumed.
The [[NFC-NDEF]] specification recommends that <a>NDEF</a> parsers store
or forward the payload without processing it.
</p>
<div>
<ndef-record
header="*,*,*,*,*,5 (UNKNOWN)"
content="0,*,*,_,*,*"
short>
</ndef-record>
</div>
</section>
<section>
<h4>
Unchanged type records (TNF 6)
</h4>
<div>
The <dfn>unchanged record</dfn>s are record chunks of
a chunked data set, and is used for any, but the first record.
A <dfn>chunked</dfn> payload is spread across multiple <a>NDEF record</a>s
that undergo the following rules:
<ul>
<li>
The initial chunk record has the <a>CF field</a> set, its
<a>TYPE field</a> set to the type of the whole chunked payload and
its <a>ID field</a> MAY be set to an identifier used for the whole
chunked payload. Its <a>PAYLOAD LENGTH field</a> denotes the size of
the payload chunk in this record only.
</li>
<li>
The middle chunk records have the <a>CF field</a> set, have the
same <a>ID field</a> as the first chunk, their
<a>TYPE LENGTH field</a> and <a>IL field</a> MUST be `0` and their
<a>TNF field</a> MUST be `6` (unchanged).
</li>
<li>
The terminating chunk record has this flag cleared, and in rest
undergo the same rules as the middle chunk records.
</li>
<li>
A chunked payload MUST be contained in a single <a>NDEF message</a>,
therefore the initial and middle chunk records cannot have the
<a>ME field</a> set.
</li>
</ul>
</div>
<div>
First record:
<ndef-record
header="1,0,1,1,0,*"
content="0,PAYLOAD LENGTH FOR THIS RECORD,_,_,_,*"
short>
</ndef-record>
<br>
Intermediate record:
<ndef-record
header="0,0,1,1,0,6 (UNCHANGED)"
content="0,PAYLOAD LENGTH FOR THIS RECORD,_,_,_,*"
short>
</ndef-record>
<br>
Last record:
<ndef-record
header="0,1,0,1,0,6 (UNCHANGED)"
content="0,PAYLOAD LENGTH FOR THIS RECORD,_,_,_,*"
short>
</ndef-record>
</div>
<p>
Any implementation of Web NFC MUST transparently expose chunked records
as single logical records.
</p>
</section>
</section>
</section> <!-- NFC Standard -->
<section class="informative"> <h3>Use Cases</h3>
<p>
A few NFC user scenarios have been enumerated
<a href="http://www.w3.org/2009/dap/wiki/Near_field_communications_%28NFC%29#Use_cases_submitted_to_DAP_mailing_list">
here</a> and in the
<a href="https://w3c-cg.github.io/web-nfc/use-cases.html">Web NFC Use Cases</a>
document. The rudimentary Web NFC interactions are the following.
</p>
<section> <h3>Reading an <a>NFC tag</a></h3>
<p>
Reading an <a>NFC tag</a> containing an <a>NDEF message</a>, while the
{{Document}} of the <a>top-level browsing context</a> 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.
</p>
</section>
<section> <h3>Writing to an <a>NFC tag</a></h3>
<div>
The user opens a web page which can write to an <a>NFC tag</a>. The write
operations may be one of the following:
<ol>
<li>
Writing to a non-formatted <a>NFC tag</a>.
</li>
<li>
Writing to an empty, but formatted <a>NFC tag</a>.
</li>
<li>
Writing to an <a>NFC tag</a> which already contains an
<a>NDEF message</a>.
</li>
<li>
Writing to other, writable <a>NFC tag</a>s (i.e. overwriting a
generic tag).
</li>
</ol>
</div>
<p class="note">
Note that an NFC write operation to an <a>NFC tag</a> always involves
also a read operation.
</p>
</section>
<section> <h3>Making an <a>NFC tag</a> read-only</h3>
<div>
The user opens a web page which can make an <a>NFC tag</a> permanently
read-only. The operations may be one of the following:
<ol>
<li>
Making a non-formatted <a>NFC tag</a> permanently read-only.
</li>
<li>
Making an empty, but formatted <a>NFC tag</a> permanently
read-only.
</li>
<li>
Making an <a>NFC tag</a> which already contains an
<a>NDEF message</a> permanently read-only.
</li>
</ol>
</div>
<p class="note">
Note that making an <a>NFC tag</a> permanently read-only always involves
a read operation.
</p>
</section>
<section> <h3>Support for multiple NFC adapters</h3>
<p>
Users may attach one or more external <a>NFC adapter</a>s to their
devices, in addition to a built-in adapter. Users may use either
<a>NFC adapter</a>.
</p>
</section>
</section> <!-- Use Cases -->
<section class="informative"> <h3>Features</h3>
<div>
High level features for the Web NFC specification include the following:
<ol>
<li>
Support devices with single or multiple <a>NFC adapter</a>s.
If there are multiple adapters present when invoking an NFC function
then the UA operates all <a>NFC adapter</a>s in parallel.
</li>
<li>
Support communication with passive (smart cards, tags, etc.) NFC devices.
</li>
<li>
Allow users to act on (e.g. read, write or transceive) discovered
passive NFC devices, as well as access the payload which were read in
the process as <a>NDEF message</a>s.
</li>
<li>
Allow users to write a payload via <a>NDEF record</a>s to compatible
devices, such as writable tags, when they come in range, as
<a>NDEF message</a>s.
</li>
</ol>
</div>
</section> <!-- Features -->
<!-- - - - - - - - - - - - - - Usage Examples - - - - - - - - - - - - - - -->
<section class="informative"> <h2>Examples</h2>
<p>
This section shows how developers can make use of the various features of
this specification.
</p>
<section><h3>Feature support</h3>
<p>
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.
</p>
<pre class="example">
if ("NDEFReader" in window) { /* Scan and write NDEF Tags */ }
</pre>
</section>
<section><h3>General information about writing data</h3>
<p>
Writing data is generally straightforward, but there are a few
gotcha's around how writing works with NFC.
</p>
<p>
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.
</p>