forked from w3c/web-nfc
-
Notifications
You must be signed in to change notification settings - Fork 0
/
security-privacy.html
728 lines (711 loc) · 29.3 KB
/
security-privacy.html
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
<!DOCTYPE html>
<html>
<head>
<title>Web NFC API Security and Privacy Considerations</title>
<meta charset="UTF-8">
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
class='remove'>
</script>
<script class="remove">
var respecConfig = {
specStatus: "CG-DRAFT",
shortName: "web-nfc",
noLegacyStyle: true,
publishDate: "",
previousPublishDate: "",
previousMaturity: "",
edDraftURI: "http://w3c.github.io/web-nfc/",
crEnd: "",
editors: [
{ name: "Kenneth Rohde Christiansen", company: "Intel",
companyURL: "http://www.intel.com/" },
{ name: "Zoltan Kis", company: "Intel",
companyURL: "http://www.intel.com/" },
],
inlineCSS: true,
noIDLIn: true,
// extraCSS: ["../ReSpec.js/css/respec.css"],
wg: "Web NFC Community Group",
wgURI: "https://www.w3.org/community/web-nfc/",
wgPublicList: "public-web-nfc",
otherLinks: [
{
key: "Repository",
data: [{
value: "We are on Github.",
href: "https://github.com/w3c/web-nfc"
}, {
value: "File a bug.",
href: "https://github.com/w3c/web-nfc/issues"
}, {
value: "Commit history.",
href: "https://github.com/w3c/web-nfc/commits/gh-pages"
}
]
},
{
key: "Contributors",
data: [{
value: "In the github repository",
href: "https://github.com/w3c/web-nfc/graphs/contributors"
}
]
},
],
localBiblio: {
"MANIFEST": {
href: "http://www.w3.org/TR/appmanifest/",
title: "Manifest for a web application",
publisher: "W3C",
date: "25 March 2015",
},
},
};
</script>
</head>
<body>
<!-- - - - - - - - - - - - - - - - Abstract - - - - - - - - - - - - - - - - -->
<section id="abstract">
<p>
This document provides a collection of security and privacy related topics
concerning web pages and applications using Near Field Communication (NFC).
More information about Web NFC can be found in the
<a href="http://w3c.github.io/web-nfc/index.html#abstract">Web NFC API</a>
specification.
</p>
</section>
<section id="sotd">
<p>
This document provides background for security and privacy related decisions
for the <a href="http://w3c.github.io/web-nfc/index.html">Web NFC API</a>.
Comments on the document should be filed as issues at
<a href="https://github.com/w3c/web-nfc/issues">
https://github.com/w3c/web-nfc/issues</a>.
</p>
</section>
<section> <h2>Terminology</h2>
<p>
For NFC terminology, please consult the
<a href="http://w3c.github.io/web-nfc/index.html#terminology">
Web NFC specification</a>.
</p>
<p>
<code><a href="http://www.w3.org/TR/url-1/"><dfn>URL</dfn></a>
</code> is defined in [[!URL]].
</p>
<p>
The term <a href="https://html.spec.whatwg.org/#browsing-context">
<dfn>browsing context</dfn></a> refers to the environment in which
<a href="https://html.spec.whatwg.org/#document">Document</a> objects are
presented to the user. A given <a>browsing context</a> has a single
<a>origin</a> and a single <code>WindowProxy</code> object, but it
can have many <code>Document</code> objects, with their associated
<code>Window</code> objects. The <i>browsing context</i> identifies
the entity which invokes this API, which can be a <i>web app</i>, a
<i>web page</i>, or an
<a href="https://html.spec.whatwg.org/#the-iframe-element">iframe</a>.
</p>
<p>
The term
<a href="https://html.spec.whatwg.org/#origin">
<dfn>origin</dfn></a> is defined in [[!HTML5]].
</p>
<p>
The term <a href="https://html.spec.whatwg.org/#ascii-serialisation-of-an-origin">
<dfn>ASCII serialized origin</dfn></a> is defined in [[!HTML5]].
</p>
<p>
<b>NFC</b> 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.
</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 attached via USB.
</p>
<p>
An <dfn>NFC tag</dfn> is a passive NFC device.
The <a>NFC tag</a> is powered by magnetic induction when an active NFC
device is in proximity range. An <a>NFC tag</a> contains a single
<a>NDEF message</a>.
</p>
<p>
An <dfn>NFC peer</dfn> is an active, powered device, which can interact
with other devices in order to exchange data using NFC.
</p>
<p>
An <dfn>NFC device</dfn> is either an <a>NFC peer</a>, or an <a>NFC tag</a>.
</p>
<p>
An <dfn>NDEF message</dfn> encapsulates one or more application-defined
<a>NDEF record</a>s. <dfn>NDEF</dfn> is an abbreviation for NFC Forum
Data Exchange Format, a lightweight binary message format. NDEF messages
can be stored on an <a>NFC tag</a> or exchanged between NFC-enabled devices.
</p>
<p>
An <dfn>NDEF record</dfn> has a maximum payload of 2^32-1 bytes. The record
also contains information about the payload size, type, and an optional
identifier. NFC Forum standardized a small set of useful data types to be
used in <a>NDEF record</a>s, 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.
</p>
<p>
Part of the <a>NDEF record</a> is the <dfn>NDEF Id</dfn> field, which may or
may not be present. If present, it contains a maximum 256 octets long
string which is a URL and it is used for identifying the payload,
in an application specific way.
</p>
<p>
The term <dfn>NFC content</dfn> is a synonym for <a>NDEF message</a>,
which can originate either from an <a>NFC tag</a> or an <a>NFC peer</a>.
</p>
<p>
The term <dfn>Web NFC origin</dfn> is the <a>ASCII serialized origin</a>
of the <a>browsing context</a> that has written the <a>Web NFC message</a>.
</p>
<p>
The <dfn>Web NFC Id</dfn> is a special <a>URL</a> stored in the
<a>Web NFC record</a>, and it is used for matching <a>NFC content</a> with
URL patterns specified by listeners.
For more details see the <a href="#web-nfc-id">Web NFC Id</a> section.
</p>
<p>
A <dfn>Web NFC record</dfn> is a special <a>NDEF record</a> which identifies
<a>Web NFC content</a> meant for web pages, rather than generic
<a>NFC content</a>. For a detailed description see the
<a href="#web-nfc-record-format">Web NFC record</a> section.
</p>
<p>
A <dfn>Web NFC message</dfn> represents a set of the <a>NDEF record</a>s
from a given <a>NDEF message</a> and a special <a>Web NFC record</a>.
For more details see the <a href="#web-nfc-message-format">Web NFC Message
format</a> section.
</p>
<p>
The term <dfn>Web NFC content</dfn> denotes all <a>Web NFC message</a>s
contained in an <a>NDEF message</a>. This version of the specification
supports one <a>Web NFC message</a> per <a>NDEF message</a>.
</p>
<p>
The term <dfn>trusted integrity NFC content</dfn> refers to an
<a>NDEF message</a>, or an <a>NDEF record</a>, which can be trusted for
data integrity, i.e. the content is not changed by third party between
writing and reading.
</p>
<p>
The key security related definitions are the following.
</p>
<p>
The term <dfn>expressed permission</dfn> 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 <a>browsing context</a> to access the
given functionality.
</p>
<p>
The term <dfn id="askforgiveness">ask for forgiveness</dfn> refers to some
form of unobtrusive notification that informs the user of an operation
while it is running.
User agents SHOULD provide the user with means to ignore similar future
operations from the same <a>origin</a> and advertise this to the user.
</p>
<p>
The term <dfn>prearranged trust relationship</dfn> means that the
user agent has already established a trust relationship for a
certain operation using a platform specific mechanism, so that an
<a>expressed permission</a> from the user is not any more needed.
See also the <a href="#prearranged-trust-relationship">
Prearranged trust relationship</a> section.
</p>
<p>
The term <dfn>obtain permission</dfn> for a certain operation indicates
that the user agent has either obtained <a>expressed permission</a>, or
<a href="#askforgiveness">asks for forgiveness</a>, or ensured a
<a>prearranged trust relationship</a> exists.
</p>
</section>
<section class="informative"> <h2>Introduction</h2>
<p>
NFC technology involves multiple levels of security. Payments done with NFC
are considered to be at least as secure as with payment cards at hardware
level, but the whole software stack needs to be security hardened.
However, data transfer (reads, writes and push) involve more threats. This
document discusses some of the relevant threats and possible remedies, as
input to API design and implementation decisions.
</p>
</section>
<section class="informative"> <h2>Security and privacy context of NFC</h2>
<p>
Discussions in <a href="https://github.com/w3c/web-nfc/issues">
issues</a> such as in
<a href="https://github.com/w3c/web-nfc/issues/2">Verify security model</a>,
<a href="https://github.com/w3c/web-nfc/issues/3">Suggest a permission UI
flow</a>, and
<a href="https://github.com/w3c/web-nfc/issues/40">Simplify process for
obtaining permissions</a> make it clear that NFC technology has a few
peculiarities with regards to content handling. In summary,
<ul>
<li>
The user must make a physical act of tapping with an NFC capable device
in order to use the technology. This action can also be involuntary,
for instance by accidentally placing the NFC capable device in the
proximity of an <a>NFC tag</a> or <a>NFC peer</a>.
Therefore other means are also needed to make sure the NFC operation is
according to the intentions of the user.
For instance, the display MUST be on, the device MUST be unlocked,
the <a>browsing context</a> using the NFC API MUST be visible and in
focus, information about ongoing NFC operation SHOULD be visible (in the
form of icons, information banners, etc).
</li>
<li>
The integrity of an <a>NDEF message</a> cannot be guaranteed, unless the
<a>NFC content</a> is encrypted. Therefore <a>NFC content</a> cannot be
handled using the same-origin policy, since the <a>origin</a> of the
content of an <a>NDEF message</a> cannot be established by means
provided by the NFC standards alone. A <a>URL</a> can be included with
<a>NFC content</a>, but it can be faked or changed by 3rd parties not
using the Web NFC API.
<p class="warning">
Malicious 3rd parties can write arbitrary URL's into the
<a>NDEF Id</a> field, and provide a prepared attack vector as data to
services which use the Web NFC API as well.
Therefore the <a>Web NFC Id</a> cannot be considered the authentic
origin of the data of the <a>NDEF message</a>.
</p>
</li>
<li>
Since user agents cannot uniquely identify <a>NFC tag</a> or
<a>NFC peer</a>s, there is no notion of "pairing" in communicating via
NFC.
Therefore each operation needs to <a>obtain permission</a> if required.
</li>
<li>
Also, there is no notion of "session" in communicating via NFC, other
than the physical proximity range maintained by the user.
</li>
<li>
The location of the user might indirectly be determined by knowing the
physical location of the NFC tag which is being read.
Also, the location of the user might be disclosed by sending
<a>NFC tag</a>s, either by directly sharing the user location (when the
<a>browsing context</a> has access to that), or by sending information
that can be used for inferring the location of the user.
Since both reading and sending <a>NFC content</a> might reveal the
location of the user, user agents SHOULD take into account the
security and privacy measures listed in the
<a href="http://dev.w3.org/geo/api/spec-source.html#security">
Geolocation API</a>.
</li>
</ul>
</p>
</section>
<section class="informative"> <h2>Trust model</h2>
<p>
Web pages using the 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. Also, implementations SHOULD
make sure that when the user authorizes an NFC operation, 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 operations.
</p>
<p>
Web apps installed from a store, or web pages installed to home screen (with
[[MANIFEST]]) MAY be considered trusted by the user agent.
</p>
</section>
<section class="informative"> <h2>Attacker model</h2>
<p>
The following patterns have been considered:
<ul>
<li>malicious web page and benign user: phishing user data</li>
<li>malicious web page and benign user: phishing user location</li>
<li>
malicious web page prepared by malicious user: web page modifies
existing NFC tag leading to indirect damage through fake identities
and attack vectors
</li>
<li>malicious web page prepared by malicious user: destroying tags.</li>
</ul>
</p>
</section>
<section class="informative"> <h2>Threats and possible solutions</h2>
<p>
<table class="simple" border="1">
<tr>
<th><strong>Threat</strong></th>
<th><strong>Comments, possible mitigation</strong></th>
</tr>
<tr>
<td>
Web page using the Web NFC API collects user data without the
consent of the user.
</td>
<td>
The user SHOULD be able to be aware of what data can be shared using
NFC from the given web page.
Use permissions and user prompts for accessing personal data,
minimize user data exposed to NFC.
</td>
</tr>
<tr>
<td>Malicious web page overwrites tags without user consent.</td>
<td>
Make sure the write is additive to previous content.
Or, require permission and user prompt needed for writing tags.
Or, control what tags can be written by a given web page, for instance
a web page can write only a tag which can be connected to its origin.
Or, allow this since tags not meant to be written can be protected
by making them read only.
</td>
</tr>
<tr>
<td>
Malicious web page writes sensitive user data to tags and peer
devices.
</td>
<td>
The user SHOULD be able to be aware of what data can be shared using
NFC from the given web page.
Use permission/user prompt for writing tags and peers.
</td>
</tr>
<tr>
<td>
Malicious tag may be involuntarily or voluntarily read by devices
and the data read may constitute an attack vector on the user agent.
</td>
<td>
This is a generic problem with all existing NFC tags.
The data is considered application specific.
Implementations need security hardening.
Involuntary touch is low probability due to short range and critical
angle for reading.
It’s easier to attack elsewhere (e.g. WiFi and Bluetooth).
</td>
</tr>
<tr>
<td>
Malicious smart poster tag attempts triggering an action on the
device which may be a threat.
</td>
<td>
Support for smart posters is not among the main use cases of Web
NFC; if and when supported, no automatic actions should be allowed,
the user must be made aware and given the ability to control what is
happening during the NFC communication.
</td>
</tr>
<tr>
<td>
Malicious Web NFC tag could send an arbitrary payload to a website
via a user’s device, along with a user’s existing web credentials.
The webapp and server would need to treat that payload as completely
untrusted.
</td>
<td>
Suggest rules for handling payload safely, provide best-practice
methods for doing so, provide a sanitization/validation function.
Payload MAY be even cryptographically signed before writing it to a
tag so the contents could later be verified.
</td>
</tr>
<tr>
<td>
A Web NFC tag could be used for leaking the user’s location, if the
reading triggers a user’s device to navigate to a website.
</td>
<td>
A Web NFC tag SHOULD NOT ever trigger a user’s device to navigate
to a website without asking permission, unless the site has been in
the foreground or has been brought to the foreground and has been
granted permission.
</td>
</tr>
</table>
</p>
</section>
<section class="informative"> <h2>Security policies</h2>
<p>
In order to minimize attack surface using the Web NFC API, user agents MAY
implement multiple security policies, for example some of the following:
<ul>
<li>
User agents SHOULD allow Web NFC API access only from top level frames
or frames where the integrity and origin of the content is secure.
</li>
<li>
In order to use NFC, a website MUST be visible and in focus. For
web pages in background, receiving and sending NFC data MUST be
suspended.
</li>
<li>
Reading of generic NFC content is allowed, if the reading page scheme is
https.
</li>
<li>
Otherwise, reading of generic NFC content is not allowed, only special
Web NFC content can be read.
</li>
<li>
Writing (pushing) is allowed only with special Web NFC content when
the writing page origin fulfills certain conditions.
</li>
<li>
The payload data on NFC content is untrusted, and SHOULD NOT be used
by the user agent to do automatic handling such as opening a web page
with a URL found in an NFC tag, unless the user approves that.
</li>
<li>
Since all local content that a web page has access to can be shared with
NFC, the user needs to be clearly aware about the permissions granted
to the web page using the Web NFC API.
</li>
</ul>
The Web NFC API specification may require the existence of some of the
policies above, and may make others optional. However, all the mechanisms
needed to implement these security policies should be supported by the
implementations.
</p>
</section>
<section class="informative"> <h2>Security mechanisms</h2>
<p>
In order to support security policies concerning the Web NFC API, certain
mechanisms are recommended for the implementations, such as:
<ul>
<li>
An identification mechanism for telling apart “Web NFC content" from
generic NFC content.
</li>
<li>
A mechanism for conveying implementation specific metadata
which is not exposed to applications.
</li>
<li>
A mechanism for obtaining <a>expressed permission</a> of the user.
</li>
<li>
A mechanism for <a>ask for forgiveness</a> policies.
</li>
<li>
A mechanism for <a>prearranged trust relationship</a>.
</li>
</ul>
</p>
<section> <h3>Prearranged trust relationship</h3>
<p>
In order to <a>obtain permission</a> to a Web NFC function, either an
<a>expressed permission</a> is needed (essentially a user prompt or
setting), or the functionality has such low security and privacy impact that
displaying information about the ongoing operation is considered enough
(also known as <a>ask for forgiveness</a>), or then a
<a>prearranged trust relationship</a> MUST be established by using specific
mechanisms of the underlying platform, and by choices made in the
implementation of the user agent.
A few examples for prearranged trust relationship are given below.
</p>
<p>
Web apps installed from a store, or web pages installed to home screen (with
[[MANIFEST]]) MAY be considered trusted by the user agent. In this case
the trust concerns the client web page, but not to the date exchanged
through NFC.
</p>
<p>
For trusting the integrity of the data exchanged via NFC, user agents MAY
use encrypted <a>NFC content</a> with key management based on Public Key
Infrastructure. Key management is out of the scope of the Web NFC
llllspecification.
</p>
<p>
When the risk of 3rd party native applications modifying and faking tags is
considered a problem deferred to native application stores, just like the
issue whether the user can trust a browser implementation or not, then
in this case user agents MAY make the choice of trusting the
data content of NFC tags and peers, and this MAY be considered a
<a>prearranged trust relationship</a> in the Web NFC API.
In that case, user agents MAY consider the <a>Web NFC Id</a> and
the <a>Web NFC record</a> as trusted information, so that origin based
browser security policies MAY be based on them.
Specifically, user prompting policies MAY be relaxed when the <a>origin</a>
of the <a>browsing context</a> requesting the Web NFC functionality is
equal to the the one saved in the <a>Web NFC Id</a> and optionally when it
matches the URL patterns saved in the access control list of
<a>Web NFC record</a> payload.
This kind of prearranged trust relationship can be applied in the case
when the user agent wants to minimize or eliminate user prompts
involved in obtaining permissions, and is able to mitigate the involved
risks in other ways.
</p>
</section>
</section>
<!--
<section class="informative"> <h2>Implementation details</h2>
<p>
This section contains discussion of implementation possibilities of security
related mechanisms. The following implementation alternatives are possible:
<ul>
<li>
Use additional NDEF records in an NDEF message, containing
metadata specific to Web NFC specific, such as identification, and
whitelists for reading and writing.
</li>
Use a specific Web NFC record format and encode the metadata specific to
Web NFC into that.
</li>
</ul>
</p>
<section> <h3>Whitelists and the <strong>NfcAccess</strong> dictionary</h3>
<p>
A <dfn>whitelist</dfn> is an array of <code>NfcAccess</code>
dictionaries.
</p>
<dl title="dictionary NfcAccess" class="idl">
<dt>USVString scope</dt>
<dt>boolean canWrite</dt>
</dl>
<p>
The <dfn id="widl-NfcAccess-scope">scope</dfn> property is a string
pattern for matching the URL's that are explicitly allowed to access
the data, for instance <br>
<code>{ "scope": "https://mydomain.com", "canWrite": "true"}</code>. <br>
Scopes which don't
<a href="http://w3c.github.io/web-nfc/#the-within-scope-algorithm">match</a> this are not permitted to access the data.
If the whitelist is empty, then the platform default policy applies,
which SHOULD permit reading for everyone, but SHOULD prevent writing,
except to URL's which
<a href="http://w3c.github.io/web-nfc/#the-within-scope-algorithm">match</a> the origin of the page which wrote the existing data.
</p>
<p>
When the <dfn id="widl-NfcAccess-canWrite">canWrite</dfn> property is
<code>true</code>, then the URL's matching <code><var>scope</var></code>
are permitted to write (in fact, update) the data, otherwise they are only permitted to read it.
</p>
<p class="issue">
The exact meaning of scope, pattern, and the matching algorithm to origins
need to be reviewed with the
<a href="http://www.w3.org/2011/webappsec/">Web Application Security WG</a>.
</p>
</section>
<section> <h3>Additional NDEF records for Web NFC</h3>
<p>
A typical Web NFC NDEF message will contain the following
NDEF records:
<ul>
<li>Normal NDEF records carrying data.</li>
<li>
Optionally, an NDEF record for Web NFC identification and configuration.
The preferred type of this NDEF record is NFC Forum External Type
(TNF=0x04), with the External Type field set to
<code>urn:nfc:ext:w3.org:webnfc</code>. The payload of this record
MAY contain implementation specific data (such as tokens, keys,
context, etc).
</li>
</ul>
This scheme allows that legacy readers could read the data records,
provided they are able to ignore the Web NFC specific record.
</p>
</section>
<section> <h3>Web NFC using encoded metadata</h3>
<p>
As an alternative to the previous section, Web NFC may also define a
record format based on NFC Forum External Type (TNF=0x04) records, where
the External Type field set to <code>urn:nfc:ext:w3.org:webnfc</code>.
The payload type is <code>application/webnfc+json</code> (encoded as
UTF-8 by default). All data is JSON, with the following schema:
<ul>
<li>
<code>id</code>: <code>"string"</code>; contains the Web NFC
identifier, e.g. the SHA256 signature of
<code>"w3.org/web-nfc”</code>. This is not strictly needed.
</li>
<li>
<code>origin</code>: <code>"string"</code>; contains the
<a href="https://html.spec.whatwg.org/multipage/browsers.html#ascii-serialisation-of-an-origin">ASCII serialized origin</a> which
has written the data. Also, this is not strictly needed, since it can
be also stored at the NDEF record's <code>id</code> field.
</li>
<li>
<code>messageType</code>: <code>"string"</code>; contains the type of
the data, either <code>"text"</code>, <code>"url"</code>,
<code>"json"</code>, or <code>"blob"</code>.
</li>
<li>
<code>message</code>: <code>"string"</code>; contains the payload data
encoded as text (text, URL and JSON), and for blob encoded as
Base64 ([[RFC4648]]).
</li>
<li>
<code>access</code>: <code>"array"</code>; contains the
<a>whitelist</a> for defining access control to the data.
</li>
</ul>
The full JSON schema is the following:
<pre title = "Web NFC JSON schema" class="example">
{
"$schema": "http://w3.org/web-nfc#",
"id": "http://w3.org/web-nfc",
"type": "object",
"properties": {
"id": {
"id": "http://w3.org/web-nfc/id",
"type": "string"
},
"origin": {
"id": "http://w3.org/web-nfc/origin",
"type": "string"
},
"messageType": {
"id": "http://w3.org/web-nfc/messageType",
"type": "string"
},
"message": {
"id": "http://w3.org/web-nfc/message",
"type": "string"
},
"access": {
"id": "http://w3.org/web-nfc/access",
"type": "array",
"items": [
{
"id": "http://w3.org/web-nfc/access/0",
"type": "object",
"properties": {
"scope": {
"id": "http://w3.org/web-nfc/access/0/scope",
"type": "string"
},
"canWrite": {
"id": "http://w3.org/web-nfc/access/0/canWrite",
"type": "boolean"
}`
}
},
]
}
},
"required": [
"origin",
"messageType",
"message",
]
}
</pre>
</p>
<p class="note">
The encoded JSON format for Web NFC data and metadata is useful for
abstracting away NFC Forum types, and for supporting implementations where
an NDEF message contains only one NDEF record.
</p>
</section>
</section>
-->
<section id="acknowledgments"> <h2>Acknowledgments</h2>
<p>
Big thanks to Jonas Sicking and Jeffrey Yasskin for the initiating thoughts,
and to Elena Reshetova and Sandeep Tamrakar for reviews and valuable
suggestions.
</p>
</section>
</body>
</html>