-
Notifications
You must be signed in to change notification settings - Fork 67
/
index.html
439 lines (409 loc) · 20 KB
/
index.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
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en-US" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>
Web NFC Community Group Charter
</title>
<link rel="stylesheet" href="https://www.w3.org/2005/10/w3cdoc.css" type=
"text/css" media="screen" />
<link rel="stylesheet" type="text/css" href=
"https://www.w3.org/Guide/pubrules-style.css" />
<link rel="stylesheet" type="text/css" href=
"https://www.w3.org/2006/02/charter-style.css" />
<style type="text/css">
/*<![CDATA[*/
.editorial { background-color: yellow }
dt { font-weight: bold; margin-top: 0.3em }
/*]]>*/
</style>
</head>
<body>
<section>
<h1 id="title">
Web NFC API Community Group Charter
</h1>
<ul>
<li>This Charter: <a href="https://w3c.github.io/web-nfc/charter/">
http://w3c.github.io/web-nfc/charter/</a></li>
<li>Start Date: 2015-03-12</li>
<li>Last Modified: 2015-04-06</li>
</ul>
</section>
<section><h2>Goals</h2>
<p>
Near-field communication (NFC) is a form of short range wireless
communication in which NFC devices such as mobile phones can communicate
with each other over a typical distance of 4cm or less. NFC allows for two
way communication. The NFC Forum defines base standards for how smart cards
are emulated by NFC devices and NFC Forum tags are formatted and the
protocols for communicating between devices. There are three modes of
operation:
<ul>
<li>read/write mode - the NFC device can read or write records, each of
which has a type. There are currently several defined record types (Text,
URI, Smart Poster, etc.). Records can be set to read-only, and protected
through encryption and digital signatures.</li>
<li>peer to peer mode - where two NFC devices exchange data, for example,
data for setting up WiFi access, or data representing a business card.
</li>
<li>card emulation mode - where an NFC device emulates a smart card, e.g.
allowing an NFC enabled phone to be used for contactless ticketing and
payment applications. Emulated cards may have limited storage
capabilities, e.g. the MiFare Classic 1K with 1024 bytes of data storage
split across 16 sectors.
</li>
</ul>
</p>
<p>
The main benefit of NFC is the speed and simplicity of operation for end
users. Touch a card to a reader to pay for ride on the metro. Touch an NFC
phone to a tag on a poster to view the web site for the associated event.
Touch two NFC phones together to exchange business cards.
</p>
<p>
In some cases no set up is needed as the card's record type is recognized
by the NFC device's operating system, which automatically launches the
appropriate application, such as the web browser. In other cases, as in
peer to peer mode, the device will first need to run the corresponding
application, which may involve asking the user to select what information
to share.
</p>
<p>
The Web Near Field Communication Community Group will define an API for Web
page scripts to use the NFC data exchange format and APDUs, enabling a
range of use cases for reading, writing, emulating cards and data exchange
with peer NFC devices. Further background information can be found on the
NFC Wiki.
</p>
</section>
<section><h2>Scope of Work</h2>
<p>
The goal is to provide a Web NFC API that satisfies the most important use
cases for NFC from Web pages. We believe that means that the API will not
expose full, low level NFC functionality, but rather a higher level subset
that is safe for Web pages, protects user privacy, and doesn't annoy users
with unnecessary or complex permission requests.
</p>
<p>
The scope of the Web Near Field Communications Community Group is limited to
the development of APIs for Web page scripts to perform the following
operations with NFC devices:
<ul>
<li>Reading NDEF messages</li>
<li>Writing NDEF messages</li>
<li> Setting NFC tags to read-only</li>
<li> Peer to peer exchange of NDEF messages between NFC devices</li>
<li>Optionally, manual connection for various technologies, e.g. NFC-A
and NFC-F</li>
<li>Optionally, initiation of NFC Card emulation mode for NFC devices,
to allow the use of a device for payments or for unlocking electronic
door locks.</li>
<li> Optionally, initiation of handover mode to Bluetooth or WiFi
technology.</li>
</ul>
</p>
<p>
The APIs will be designed to permit execution in the Web browser context,
using the security model of the Web. The very short range of NFC devices
requires users to make a conscious decision to put one of the devices into
the appropriate mode and to bring the devices physically together, and
this should enable a simpler security model that minimizes the need for
applications to ask for explicit user permission. The need for direct user
involvement under circumstances will need to be explored.
</p>
<p>
The CG will explore permission models that take advantage of the
physical properties of the NFC connection to align user expectations with
the permissions actually granted to script. Aspects of the environment that
might go into the permission model include:
<ul>
<li>Whether the script is running in the frontmost tab or window.</li>
<li>Whether the script is running in an open tab or window (vs. a Service
Worker)</li>
<li>Whether the script has been vouched for by a trusted authority, such
as applications installed from a store or shipped with a device.</li>
<li>The user's interactions with permission and choice prompts.</li>
<li>Preferences expressed by the tag or peer NFC device itself.</li>
<li>Whether the application has been given additional trust by being
"installed", ie. added to the home screen.</li>
</ul>
The Community Group will also explore the
possibility of sites registering with the user agent for particular types
of messages. When multiple registrations are made for a particular type of
message, a chooser is shown to the user to select among sites to handle the
available message. Considerations like these could simplify user
interactions for granting permissions while preserving privacy and security.
The CG will explore permission systems that allows users to control in a
clear and concise way the nature of NFC interaction between pages and NFC
tags or devices. For instance, answering “yes” to a permission dialog for
using NFC during a read use case must not enable NFC usage in general, and
particularly must not enable a page to overwrite a writable tag in a way
the user did not clearly expect. Nor can it mean that a web site can
initiate a P2P communication with an NFC device which can have effects that
the user did not intend.
The Community Group may consider both an API for use by an untrusted
web site, as well as an enhanced API available to a web site is considered
trusted.
</p>
<p>
The CG will consider requiring that for riskier API's, the user has agreed
to allowing a potentially risky or experimental API for a particular trusted
web site.
The web site is known through use of HTTPS so some APIs could be restricted
to use only by known, trusted web sites. The CG could also consider use of
some APIs only for sites in the local network
(if permitted by the user). For example, where a device in the local network
offers a web page (using https), the user could grant that web page
permissions beyond what normally is allowed for random web pages. That
would allow for a set of APIs, one safe for any web site and then perhaps
others that require higher levels of trust and permission.
</p>
</section>
<section><h3>Out of Scope</h3>
<p>
The Community Group will be implemented on top of NFC implementations
provided by the platform. Low level NFC specification is out of scope.
</p>
</section>
<section><h2>Deliverables</h2>
<section><h3>Community Group Reports that are Specifications</h3>
<p>
The CG will define a Web NFC API specification, suitable for use from Web
Browsers. The CG may also create a specification related to permissions
and security governing availability or use of APIs. This could include
defining particular message content related to permissions and security.
The CG is free to arrange these specifications into one or more
specifications for convenience. However, all Specifications being worked
on must be clearly indicated on the CG Web page.
Example of what the specification could look like:
<a href="http://w3c.github.io/web-nfc/">
http://w3c.github.io/web-nfc/</a>.
</p>
</section>
<section><h3>Community Group Reports that are not Specifications </h3>
<p>
The group MAY produce other Community Group Reports within the scope of
this charter but that are not Specifications covered by the CLA, for
instance use cases, permission ceremonies, security hardening reports,
etc.
</p>
</section>
<section><h3>Test Suites and Other Software</h3>
<p>
At present, there are no plans to create a test suite. If, however, the
CG decides to develop a test suite, it will be developed in Open Source
using the W3C Software License.
</p>
</section>
</section>
<section><h2>Dependencies or Liaisons</h2>
<p>
This group’s specifications have no direct dependencies on any other
developing specification other than the Web Applications Working Group’s
Web IDL specification, which many W3C specs depend upon. However, several
other groups would provide valuable feedback and they will be asked to
review drafts.
</p>
<dl>
<dt>Device APIs Working Group</dt>
<dd>
The NFC Community Group will coordinate with the Device APIs Working Group
to ensure that the NFC API can be used effectively together with Web
Intents.
</dd>
<dt>HTML Working Group</dt>
<dd>
The NFC Community Group will coordinate with the HTML Working Group to
ensure that the NFC APIs conform to the privacy and security model for
Web browsers.
</dd>
<dt>Web Security Interest Group</dt>
<dd>
The Web Security Interest Group should be asked to review deliverables to
secure reviews on its deliverables from the Web Security Interest Group
to ensure they offer the right level of security.
</dd>
<dt>Privacy Interest Group</dt>
<dd>
The Privacy Interest Group should be asked to review deliverables for
privacy considerations.
</dd>
<dt>Web Cryptography Working Group</dt>
<dd>
Interaction with this group would be valuable for the potential synergies
between work on JavaScript cryptographic APIs and access to secure
elements on NFC devices.
</dd>
<dt>Web Bluetooth Community Group</dt>
<dd>
The Web Bluetooth Community Group should be asked to review deliverables
to take advantage of their general expertise in exposing wireless
technologies for Web standards. The NFC CG will closely follow the work
of the Web Bluetooth CG, exploring the similarities of the approach on
using these technologies by Web pages.
</dd>
<dt>Trust and Permissions Community Group</dt>
<dd>
The Trust and Permission Community Group may explore the notion of trusted
web sites, which would allow use of enhanced APIs that are available for
use only in trusted pages.
</dd>
<dt>WAI Protocols and Formats Working Group</dt>
<dd>
The WAI Protocols and Formats Working Group should be asked to review
deliverables in order to ensure the API supports accessibility
requirements, particularly with regard to interoperability with assistive
technologies, and inclusion in the deliverable of guidance for
implementing the group’s deliverables in ways that support accessibility
requirements.
</dd>
<dt>Internationalization Activity</dt>
<dd>
The Community Group will ask for reviews to ensure any I18N issues in the
API are addressed.
</dd>
<dt>NFC Forum</dt>
<dd>
The NFC Community Group will liaise with the NFC Forum to ensure that the
W3C NFC API is compatible with the NDEF specifications defined by the
NFC Forum.
</dd>
<dt>ISO and ECMA</dt>
<dd>
The NFC Community Group will build upon the capabilities provided by NFC
related standards developed by ISO/IEC/JTC 1 SC 6 and SC 17, and by Ecma
International.
</dd>
</dl>
</section>
<section>
<h2>Community and Business Group Process</h2>
<p>Terms of in this charter that conflict with those of the Community and
Business Group Process are void.</p>
</section>
<section>
<h2>Work Limited to Charter Scope</h2>
<p>The group will not publish Community Group Reports that are
Specifications other than those described in "Community
Group Reports that are Specifications" above. See below for how to modify
the charter.</p>
</section>
<section>
<h2>Contribution Mechanics</h2>
<section>
<h3>Who can make Contributions</h3>
<p>Contributions can only be made by Community Group Participants (so all
Contributors have agreed to the CLA). Particular care must be taken to
ensure Contributions of content that is implementable comes from
Community Group participants.</p>
</section>
<section>
<h3>How Contributions are made</h3>
<p>Community Group Participants agree that all Contributions will be
documented in pull requests and commits for a particular document in
the group's GitHub repository.</p>
<section>
<h4>Specifications</h4>
<p>For Contributions to Specifications, if someone other than the
Contributor makes the pull request, the pull request SHOULD indicate who
the request was made on behalf of and SHOULD provide a reference to the relevant
archived GitHub Issue or group mail thread where practical. The information
SHOULD be specific enough to easily determine who the Contributors were
and that the intention was to change a particular Specification.
In the commit, if practical, this information SHOULD be in the form
{Contributors: ["githubusername1","githubusername2"]}.</p>
</section>
<section>
<h4>Software</h4>
<p>For software, the GitHub Contributing and License files describes
how to Contribute and the license under which Contributions are made.</p>
</section>
</section>
</section>
<section>
<h2>Decision Process</h2>
<p>This group will seek to make decisions when there is consensus. When
the group discusses an issue on the mailing or Issues list and there is a
call from the group for assessing consensus, after due consideration of
different opinions, the Chair should record a decision and any
objections.</p>
<p>A common way to determine consensus for important decisions is to
conduct a Call for Consensus (CfC) where the Chair puts a proposal to the
group on the public mail list and asks for feedback from the Participants
within some period of time that is at least 7 days. Not responding
indicates going along with the proposal. Direct feedback is encouraged,
especially to weigh the degree of consensus when there is dissent.</p>
<p>Participants MAY call for an online vote if they feel the Chair has
not accurately determined the consensus of the group or if the Chair
refuses to assess consensus. This should be a rare event, only where the
usual, less formal means of making decisions are not accepted. At least 5
Participants, no two from the same organization (or 50% of the
organizations and individuals, whichever is smaller), MUST agree with the
call for a formal vote. The call for a vote MUST specify the duration of
the vote which MUST be at least 7 days and should be no more than 14
days. The Chair MUST start the vote within 7 days of the request, or
group members MAY start it themselves. The decision will be based on the
majority of the ballots cast. It is the Chair's responsibility to ensure
that the decision process is fair, respects the consensus of the CG, and
does not unreasonably favor or discriminate against any group participant
or their employer.</p>
</section>
<section>
<h2>Transparency</h2>
<p>The group will conduct all of its technical work in public.</p>
<p>Discussions MAY take place on the group's public mailing list. Other
discussions MAY take place using Issues in the group's GitHub repository.
For convenience, GitHub issues and pull requests will be archived to the
group's contrib list. Other contributions MAY be directly posted to the
contrib list.</p>
<p>Meetings MAY be restricted to Community Group participants, but a public
summary or minutes MUST be posted to the group's public mail list.</p>
<p>Any decisions reached at any meeting are tentative. Any group
participant may object to a decision reached at a meeting within 7 days
of publication of the decision on the mail list. That decision must then be
confirmed on the mail list by the Decision Process above.</p>
</section>
<section>
<h2>Chair Selection</h2>
<p>Participants in this group choose their Chair(s) and can replace their
Chair(s) at any time using whatever means they prefer.</p>
<p>The following process is used if the less formal process above is not
acceptable to group members. If 5 participants, no two from the same
organization, (or 50% of the organizations and individuals, whichever is
smaller) call for an election, the group must use the following process
to replace any current Chair(s) with a new Chair, consulting the
Community Development Lead on election operations (e.g., voting
infrastructure and using RFC 2777). Participants announce their
candidacies. Participants have 14 days to announce their candidacies, but
this period ends as soon as all participants have announced their
intentions. If there is only one candidate, that person becomes the
Chair. If there are two or more candidates, there is a vote. Otherwise,
nothing changes. Participants vote. Participants have 21 days to vote for
a single candidate, but this period ends as soon as all participants have
voted. The individual who receives the most votes —no two from the same
organization— is elected chair. In case of a tie, RFC2777 is used to
break the tie. An elected Chair may appoint co-Chairs. Participants
dissatisfied with the outcome of an election may ask the Community
Development Lead to intervene. The Community Development Lead, after
evaluating the election, may take any action including no action.</p>
</section>
<section>
<h2>Amendments to this Charter</h2>
<p>The group MAY decide to work on a proposed amended charter, editing
the text using the Decision Process described above. The decision on
whether to adopt the amended charter is made by conducting a 30-day vote
on the proposed new charter. The new charter, if approved, takes effect
on either the proposed date in the charter itself, or 7 days after the
result of the election is announced, whichever is later. A new charter
must receive 2/3 of the votes cast in the approval vote to pass. The
group may make simple corrections to the charter such as deliverable
dates by the simpler group decision process rather than this charter
amendment process. The group will use the amendment process for any
substantive changes to the goals, scope, deliverables, decision process
or rules for amending the charter.</p>
</section>
</body>
</html>