-
Notifications
You must be signed in to change notification settings - Fork 22
/
Copy pathhasec-charter.html
443 lines (430 loc) · 21.9 KB
/
hasec-charter.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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html><html
lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=UTF-8" />
<title>Draft Hardware Security (HaSec) Working Group Charter</title>
<link type="text/css" href="https://www.w3.org/2005/10/w3cdoc.css" rel="stylesheet" />
<link href="https://www.w3.org/Guide/pubrules-style.css" type="text/css"
rel="stylesheet" />
<link href="https://www.w3.org/2006/02/charter-style.css" type="text/css"
rel="stylesheet" />
</head>
<body>
<div id="template">
<ul style="font-size: small;" id="navbar">
<li><a href="#scope">Scope</a></li>
<li><a href="#deliverables">Deliverables</a></li>
<li><a href="#coordination">Dependencies</a></li>
<li><a href="#participation">Participation</a></li>
<li><a href="#communication">Communication</a></li>
<li><a href="#decisions">Decision Policy</a></li>
<li><a href="#patentpolicy">Patent Disclosures </a></li>
<li><a href="#about">About this Charter</a></li>
</ul>
<p><a shape="rect" href="https://www.w3.org/"><img width="72" height="48"
src="http://www.w3.org/Icons/w3c_home" alt="W3C" /></a> <a shape="rect"
href="https://www.w3.org/TandS/" class="domainlogo"><img alt="TandS Domain"
src="http://www.w3.org/Icons/tands.gif" /></a> </p>
<h1 id="title"><strong>DRAFT</strong><br />
Hardware Security (HaSec) Working Group Charter</h1>
<p>STATUS: Obsolete. This draft charter was reviewed in March-April 2016 and not approved at that time. Related work
continues in the <a href="https://www.w3.org/community/hb-secure-services/">Hardware-Based Secure Services Community Group.</a></p>
<p class="mission"> The <strong>mission</strong> of the <a href="Overview.html">Hardware Security Working Group</a>,
part of the <a href="../../Security/Activity.html">Security Activity</a>, is to define a set of Hardware-Based Web Security standard APIs providing Web Applications access to secure services enabled by hardware modules </p>
<div class="noprint">
<p class="join"><a href="https://www.w3.org/2004/01/pp-impl/@@number@@/join">Join
the Hardware Security Working Group</a>.</p>
</div>
<table class="summary-table">
<tbody>
<tr id="Duration">
<th>End date</th>
<td>31 December 2016</td>
</tr>
<tr>
<th>Confidentiality</th>
<td>Proceedings are <a href="https://www.w3.org/2015/Process-20150901/#confidentiality-levels">Public</a>.
</td>
</tr>
<tr>
<th>Initial Chairs</th>
<td>
<ul>
<li>Virginie Galindo, Gemalto</li>
<li>David Rogers, Copper Horse</li>
</ul>
</td>
</tr>
<tr>
<th>Initial Team Contacts<br />
(FTE %: 20)</th>
<td>Rigo Wenning</td>
</tr>
<tr>
<th>Usual Meeting Schedule</th>
<td>Teleconferences: Teleconferences to be held approximately
weekly or biweekly as required.
Task Forces may have separate calls that will not overlap with
others.<br />
Face-to-face: Up to 3 per year as required</td>
</tr>
</tbody>
</table>
<div class="goal">
<h2 id="goal">Goals</h2>
<p> The Hardware-Based Web Security Working Group will develop
recommendation-track documents that define a standard to provide
secure services for high security Web applications. </p>
<p> There are a number of use cases that this standard will enable,
including but not limited to the ability to encrypt and to decrypt
data using hardware based encryption modules, the ability to
manage credential information for hardware based security modules,
and the ability to access specific security sensitive services
offered by hardware tokens. Such security sensitive services may
include: </p>
<ol>
<li>Payments – transaction authorization</li>
<li>Identity verification</li>
</ol>
</div>
<div class="scope">
<h2 id="scope">Scope</h2>
<p>
This Working Group’s scope is Hardware-Based Web Security
standard services, enabling Web pages the use of secure
services enabled by security modules (TEE, secure elements,
and other secure enablers with a demonstrated robustness to
physical or software attacks). The group may produce
non-Recommendation track documents within this scope.
Recommendations are limited to the Restricted Scope Items
described below.
</p>
<p>
Specifications like those to be produced by this group could
impact user privacy and potential anonymity. Special care will
be taken to avoid introducing fingerprinting and tracking
threats in deliverables from this group. One mechanism to
alleviate these potential problems is to place permission to
use some functions under the user's control in a way in which
the user understands the privacy implications. The group will
seek review from the Privacy Interest Group.
</p>
<h3>Restricted Scope for Recommendation Track Deliverables</h3>
<p>
The Working Group Scope for Recommendation Track Deliverables
will be restricted during this Charter period to the following
Restricted Scope Items. Recommendation deliverables may only
be added if they clearly fall within a Restricted Scope Item
here. Restricted Scope Items must be carefully described so
the types of technologies needed for implementation are clear.
The group must recharter to add new Restricted Scope Items.
</p>
<ul>
<li>
<strong>Secure Hardware Discovery &
Attestation:</strong> Means of requesting access to a
service that satisfies some criteria, with user approval.
Means of indicating to the requesting Web page what party
vouches that the service satisfies the criteria (e.g.
digitally signed challenge; indication if Secure Hardware
Component is isolated from Operating System, or just from
Web Browser/UA). The other restricted scope items could be
satisfied through references to some existing spec along
with a way to request and verify the level of security of
the implementation. For example, a secure worker restricted
scope item (see below) could be satisfied by something like
1) reference to the Web Worker spec; 2) a means of
requesting that a Worker be executed in an environment that
cannot be tampered with even by the operating system and the
response is signed by a trusted party verifying the
implementation is available (with a nonce to prevent replay)
and a token to use to request starting a worker in that
environment; 3) extension to Web Workers creation to include
passing the token; 4) API for the running Worker to ask
environment to sign a challenge for attestation of the
environment it is running in.
</li>
<li>
<strong>Secure Hardware Crypto Key Discovery:</strong>
Discovery of pre-provisioned, named, origin specific
cryptographic keys for use with the Web Crypto API or an API
provided by this WG.
</li>
<li>
<strong>Secure Hardware Crypto Key Management:</strong>
Importing, creating, deleting keys for a particular origin.
Working Group would define trust/permission model for use of
cryptographic functions.
</li>
<li>
<strong>Secure Hardware Crypto API:</strong> Maintenance or
extension of the Web Crypto API after the first version. May
also define other Crypto API specifically for Secure
Hardware.
</li>
<li>
<strong>Secure Hardware Storage API:</strong> Origin specific
storage and retrieval of data. This would prevent access by other
applications on the device or even from the operating system depending
on the level of security provided. This API could be restricted
to be used only by a Secure Worker. This API must use or enhance
(an) existing Web Platform storage API(s), not create a new
storage mechanism. Additional APIs defined by the group could
provide a way for the Secure Worker to determine whether stored
data was already encrypted by the implementation so that the
Secure Worker could decide whether to encrypt stored data itself.
The Working Group could decide to make that API also available
for querying in Web pages about normal storage implementations
outside Secure Workers (to determine if they are encrypted
sufficiently).
</li>
<li>
<strong>Secure Hardware IO:</strong> Means to ask for and
obtain user input that is protected against compromised
operating system or UA/Browser depending on the level
provided. This could return a digitally signed (by the
hardware component) response from the user. This API is
intended to be used only by a Secure Worker, as an optional
API, and could be a very small subset of HTML for form
input.
</li>
<li>
<strong>Secure Worker:</strong> API to execute JavaScript or
WebAssembly code in a Secure Hardware Component (allowing,
but not necessarily requiring both scripting languages).
Like a Web Worker this would communicate to the calling Web
page code using a message channel provided by the User
Agent/Browser. A Secure Worker would not necessarily have
the same APIs available as a Web Worker and the spec would
define the type of data that may be passed. APIs used by
Secure Workers would be included by reference to
specifications created under other Restricted Scope Items or
other external sources. This Restricted Scope Item covers
what is needed to create, execute and communicate with
Secure Workers. Sharing Secure Workers could be restricted
to be used from the context that created them, or could also
be used from other contexts (tabs, iframes) from the same
origin, or to other origins it specifies that it permits
(like CORS).
</li>
<li>
<strong>Binding mechanism:</strong> Means to bind the result
of a secure communication to a secure hardware to a certain
context, origin or transaction and restrict the validity of
bearer tokens and other secure vouchers accordingly.
</li>
<li>
<strong>Identity semantics:</strong> Means to extract
identity information from a secure hardware under control of
the user, including the choice or creation of the subsequent
data format made available via the API.
</li>
</ul>
<h3>Web Services Interfaces</h3>
<p>
Services defined in this Working Group (under the Restricted Scope Items)
could also be exposed, in Recommendation Track Deliverables, through Web
Services to a nearby device or to the cloud. The APIs would additionally
be described in terms of message content (e.g using JSON) that could be
delivered by means like RESTful Web Services, Web Sockets, or some other
message delivery mechanism. That would allow the same security services
to be used outside the Web Browser context, in the Internet of Things
for example, or as services from the cloud.
</p>
<h3>Out of Scope</h3>
<p>
The Working Group does not define how hardware security is
accomplished. It defines how to ask hardware security for
basic services where a secure hardware environment is
available. The group will also not define crypto algorithms.
</p>
<h3 id="success">Success Criteria</h3>
<p>The Group is successful if the following criteria are met:</p>
<ul>
<li>
Participation via mailing list subscription and postings from
people representing various stakeholder communities, including
banks, payment industry, various legal and regulatory bodies
with mandates that are related to authentication, authorization
and secure transmission, hardware and software developers,
mobile operator companies, browser vendors and developers of
secure applications
</li>
<li>
Discussion of requirements and use cases and publishing a
Working Group NOTE on use cases and requirements for
hardware based security on the Web. The NOTE will determine
the priority of the restricted items in section 2.1 to be
addressed
</li>
<li>Successfully engage and coordinate with Groups working on Web
Applications and their components as well as with other Security
Groups within W3C and beyond
</li>
<li>Engage a dialog with the governmental identity systems that
require a higher level of security
</li>
</ul>
</div>
<div id="deliverables">
<h2>Deliverables</h2>
<h3>Recommendation-Track Deliverables</h3>
<p>
Deliverables will be identified from among those listed in 2.1
and chosen by Working Group consensus. All Recommendations
must have associated use cases describing the scenarios that
the deliverable is intended to enable. These will be used to
guide specification development. Use cases are not normative
interoperability specifications. They are informative, so do
not need to be in a REC track document.
</p>
<p>
The group may produce Recommendation-Track deliverables within
the scope of the Restricted Scope Items of this Charter. These
deliverables, when chosen by the Working Group, will be listed
on the group’s homepage or the GitHub repo linked from the homepage,
under the Restricted Scope Item in which they fit. When rechartering,
specific Recommendation-Track deliverables could also be listed,
but none are listed in this Charter.
</p>
<h3>Other Deliverables (not W3C Recommendations)</h3>
<p>
The group may also develop other deliverables that are not
Recommendations. These are not limited by the Restricted
Scope. As described above, these must be within the Working
Group Scope. This could include use cases or best practices
for using the APIs being developed or to explore possible
future work in developing future versions of this Charter.
</p>
<p>
The Working Group will liaise with the Web Payments Working
Group on web payments access. The expected non normative
deliverables with Web Payments WG are use case and an
architecture document, focusing on payment integration in the
web payment API designed when payment means relies on
hardware.
</p>
</div>
<div id="dependencies">
<h2>Dependencies and Liaisons</h2>
<h3>Internal liaisons</h3>
<ul>
<li><a href="https://www.w3.org/WebPlatform/WG/">Web Platform Working Group</a></li>
<li><a href="https://www.w3.org/Payments/WG/">Web Payments Working Group</a></li>
<li><a href="https://www.w3.org/2011/webappsec/">Web Application Security Working Group</a></li>
<li><a href="https://www.w3.org/2012/webcrypto/">Web Cryptography Working Group</a></li>
<li><a href="https://www.w3.org/WAI/APA/">Accessible Platform
Architectures (APA) WG</a> to identify and address potential accessibility issues on
the level of UI, APIs, and assistive technologies.</li>
</ul>
<h3>External liaisons</h3>
<p>There are a number of external groups working in areas related to
the ones in scope for the HaSec WG. The Working Group should
determine whom to communicate with and then maintain communication
with them. The following groups are likely to be important: </p>
<ul>
<li><a href="https://fidoalliance.org/">FIDO Alliance (Fast IDentity Online)</a></li>
<li><a href="http://www.trustedcomputinggroup.org/">Trusted Computing Group (TCG)</a></li>
<li><a href="https://www.globalplatform.org/">GlobalPlatform</a></li>
<li><a href="https://www.etsi.org/">European Telecommunications Standards Institute (ETSI)</a></li>
</ul>
</div>
<div class="participation">
<h2 id="participation">Participation</h2>
<p>Participation is open to W3C Members and Invited Experts. </p>
<p>In order to make rapid progress, the group MAY form several Task
Forces (TFs), each working on a separate topic. Group members are
free to join any number of TFs. </p>
</div>
<div class="communication">
<h2 id="communication">Communication</h2>
<p>
This group primarily conducts its technical work on the public
mailing list at <a href="mailto:public-hasec-wg@w3.org">public-hasec-wg@w3.org</a>
(<a href="https://lists.w3.org/Archives/Public/public-hasec-wg/">archive</a>).
See <a href="https://www.w3.org/Mail/">W3C mailing list and archive usage
guidelines</a>. There is also a member-only list to be used for
administrative or member-confidential purposes at <a href="mailto:member-hasec-wg@w3.org">
member-hasec-wg@w3.org</a> (<a
href="https://lists.w3.org/Archives/Member/member-hasec-wg/">archive</a>).
</p>
<p>
Information about the group (documents under review, face-to-face
meetings, etc.) is available from the <a href="/2015/hasec/">Web
Hardware Security Working Group home page</a>.
</p>
</div>
<div class="decisions">
<h2 id="decisions">Decision Policy</h2>
<p>
The group will aim to proceed by consensus.
</p>
<p>
Where there is consensus among the Working Group Participants,
it will be forwarded as a consensus position. Where the group
does not reach agreement, the different positions will be
considered together.
</p>
<p>
All technical resolutions made by a meeting of the group are
provisional until two weeks after being published to the mailing
list. An objection made on the mailing list within two weeks of
publishing a decision has the same standing as if it were made at
the meeting.
</p>
</div>
<div class="patent">
<h2 id="patentpolicy">Patent Policy</h2>
<p>
This Working Group operates under the <a
href="https://www.w3.org/Consortium/Patent-Policy-20040205/">W3C
Patent Policy</a> (5 February 2004 Version). To promote the
widest adoption of Web standards, W3C seeks to issue
Recommendations that can be implemented, according to this policy,
on a Royalty-Free basis.
</p>
<p>
The Hardware Security Working Group also provides an opportunity
to share perspectives on the topic addressed by this charter and
create best practices documents. Those are not subject to the
Patent Policy. W3C reminds Participants of their obligation to
comply with patent disclosure obligations as set out in <a
shape="rect"
href="/Consortium/Patent-Policy/#sec-Disclosure">Section 6</a> of
the W3C Patent Policy for those non-Recommendation-Track
deliverables.
</p>
<p>
For more information about disclosure obligations for this
group, please see the <a shape="rect"
href="/2004/01/pp-impl/">W3C Patent Policy Implementation</a>.
</p>
</div>
<h2 id="about">About this Charter</h2>
<p>
This charter has been created according to <a shape="rect"
href="/Consortium/Process/groups#GAGeneral">section 5.2</a> of
the <a shape="rect" href="/Consortium/Process">Process
Document</a>. In the event of a conflict between this document
or the provisions of any charter and the W3C Process, the W3C
Process shall take precedence.
</p>
<hr style="margin-top:20px;clear:both" />
<address> WG Chair: Virginie Galindo (Gemalto)</address>
<address> HaSec Team Contact: Rigo Wenning </address>
<p class="copyright">
<a shape="rect" href="/Consortium/Legal/ipr-notice#Copyright"
rel="Copyright">Copyright</a>© 2015 <a shape="rect" href="/">
<acronym title="World Wide Web Consortium">W3C</acronym></a>
<sup>®</sup> (<a shape="rect" href="http://www.csail.mit.edu/">
<acronym title="Massachusetts Institute of Technology">MIT</acronym></a> ,
<a shape="rect" href="http://www.ercim.eu/"><acronym title="European
Research Consortium for Informatics and Mathematics">ERCIM</acronym></a> ,
<a shape="rect" href="http://www.keio.ac.jp/">Keio</a>,
<a href="http://ev.buaa.edu.cn/">Beihang</a>),
All Rights Reserved.
</p>
<p>Last update: $Id$</p>
</body>
</html>