-
Notifications
You must be signed in to change notification settings - Fork 22
/
Copy pathhbss.html
910 lines (806 loc) · 55 KB
/
hbss.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
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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">
<html dir="ltr" about="" property="dcterms:language" content="en" xmlns="http://www.w3.org/1999/xhtml" prefix="bibo: http://purl.org/ontology/bibo/" typeof="bibo:Document">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Hardware Based Secure Service features</title>
<link href="https://www.w3.org/community/src/css/spec/cg-draft.css" rel="stylesheet" type="text/css" charset="utf-8">
<link rel="stylesheet" href="https://www.w3.org/TR/WebIDL/WebIDL.css" type="text/css">
</head>
<body>
<div class="head">
<p>
<a href="http://www.w3.org/">
<img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C">
</a>
</p>
<h1 property="dcterms:title" class="title" id="title">Hardware Based Secure Services features</h1>
<h2 property="bibo:subtitle" id="subtitle">Draft version - 29 August 2016</h2>
<dl>
<dt>Latest version</dt>
<dd>
<a href="https://rawgit.com/w3c/websec/gh-pages/hbss.html">https://rawgit.com/w3c/websec/gh-pages/hbss.html</a>
</dd>
<dt>History</dt>
<dd>
<a href="https://github.com/w3c/websec/commits/gh-pages/hbss.html">https://github.com/w3c/websec/commits/gh-pages/hbss.html</a>
</dd>
<dt>Issues</dt>
<dd>
<a href="https://github.com/w3c/websec/issues/new">File a issue</a> (<a href="https://github.com/w3c/websec/issues?q=is%3Aopen+is%3Aissue+label%3Ahbss">open issues</a>)
</dd>
<dt>Editor</dt>
<dd><a href="mailto:sebastien.bahloul@safrangroup.com">Sebastien Bahloul</a> / Safran Identity & Security</dd>
<dd>Aurelien Couvert / Gemalto</dd>
</dl>
<p class="copyright">Copyright © 2016 the Contributors to the Hardware Based Secure Service CG Specification,
published by the <a href="https://www.w3.org/community/hb-secure-services/">Hardware Based Secure Services</a>
under the <a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a>.
A human-readable <a href="http://www.w3.org/community/about/agreements/cla-deed/">summary</a> is available.</p>
<hr>
</div>
<section id="abstract">
<h2>Abstract</h2>
<p>TBD</p>
</section>
<h2>Status of This Document</h2>
<p>
<em>This specification was published by the <a href="https://www.w3.org/community/hb-secure-services/">Hardware Based Secure Services</a>.
It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href="http://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a> there is a limited opt-out and other conditions apply. Learn more about <a href="http://www.w3.org/community/">W3C Community and Business Groups</a>.</em>
</p>
<p>Working copy</p>
<h2 class="introductory">Table of Contents</h2>
<ul>
<li>1. <a href="#sec-introduction">Introduction</a></li>
<li>2. <a href="#sec-problem">Problem Statement</a></li>
<li>3. <a href="#sec-usecases">Use cases</a></li>
<li>4. <a href="#sec-api">Secure transaction and secure credential storage APIs</a></li>
<li>5. <a href="#sec-implementation">Implementation requirements</a></li>
<li>6. <a href="#sec-todo">TODO</a></li>
<li>7. <a href="#sec-dependencies">Dependencies</a></li>
<li>A. <a href="#sec-reference">References</a></li>
</ul>
<!-- OddPage -->
<h2><span class="secno">1. </span><dfn id="sec-introduction">Introduction</dfn></h2>
<p>
The open web platform runs on diverse devices such as tablets, PCs, smart phones, and cars' systems. Driven by an expectation from users and service providers, a majority of those devices are embedding some technology allowing to offer some secure services. One can think about secure chips such as embedded secure element, TPM, UICC, or proximity smart card, using BLE or NFC communication means. Another technology getting traction is the Trusted Execution environment. Both types of technology are offering some advantages in terms of secure execution and storage. Secure elements and TEEs can offer some services, known as Secure Services, to improve the integrity and confidentiality of data transactions.
</p>
<p>
This document is proposing some use cases where the web apps could benefit from secure services. In addition, in order to demonstrate the feasibility of such secure services, the Hardware Based Secure Services Community Group has identified two services, for which technical rationale and API will be detailed. In addition some protoypes, testing the reliablility of the architecture, will be developed. The elected secure services are (1) secure transaction confirmation and (2) secure credential storage.
</p>
<h3><span class="secno">1.1 </span>Terminology</h3>
<ul>
<li>Secure Service: any web site that manages sensitive operations and would benefit from/depend upon the use of an hardware based security solution to give the security proof of the user confirmation integrity and non repudiation</li>
<li>Relying party: the Web application providing the Secure Service and requesting the hardware access</li>
<li>Issuing authority: the issuing authority is in charge of issuing an associated key/identity pair to a known identity and to maintain its lifecycle. The end-user identification is out-of-scope of this document but is clearly mandatory to associate a key to a genuine identity. As an example, in the well known in X509 certificates scheme, the issuing authority is the certificate authority</li>
<li>Origin: with reference to the Same Origin Policy, in this document an origin refers to an HTTP URL with scheme, host, port without path</li>
<li>User Agent (UA): a user agent is software (a software agent) that is acting on behalf of a user (from <a href="https://en.wikipedia.org/wiki/User_agent">Wikipedia</a>)</li>
<li>User Verification Method: This is the way that the Hardware Secure Device ensures that only a natural and genuine person with possession and knowledge is able to access the keys stored in the Secure Element. For example, this method could be knowledge of a PIN code or biometric verification</li>
<li>Identity: to be verified by the issuing authority, the identity is cryptographically linked to the key demonstrating who has confirmed a transaction or signed a document</li>
<li>Key: asymmetric cryptographic public/private key pair, sometimes linked to an identity</li>
<li>Hardware Secure Device: addition of the Secure Credential Storage and the Trusted User Interface with a trusted path between them</li>
<li>Secure Element: A secure element is a tamper proof device, providing a secure storage and execution environment for sensitive data and processing. It offers both physical and logical protection against attacks, ensuring integrity and confidentiality of its content.</li>
<li>Trusted User Interface: User interface component outside the direct browser scope providing
an additional level of trust in regards to the transaction confirmation message presented to the end-user to acquire its acknowledgment. It covers both the display of the information and the input of the user verification method.</li>
</ul>
<h2><span class="secno">2. </span><dfn id="sec-problem">Problem Statement</dfn></h2>
<p>At this time Secure Element are not yet usable by web applications. For years, various form factors have been usable thanks to many native API and technologies (PKCS#11, Microsoft API like CSP / Minidriver, Java applet ...). Use cases are valid for native applications but browsers have not been working on integrating those technologies. The need to use secure services in all types of application (native, web app, hybrid) is becoming important, especially on the mobile devices. This document aims to define the next generation Javascript API for two specific requirements for hardware based key management and usage: Secure transaction confirmation and Secure credential storage. These two requirements have been identified by the Hardware Based Secure Services Community Group as being as key to enable a strong security and identity ecosystem.</p>
<p>The management of keys is associated with the problem of key usage. On the open web platform, the security principle that prevails everywhere is the Same Origin Policy. This strict policy may have some limitation in some specific cases, where several parties are involved in the delivery of a secure service.</p>
<p>Same Origin Policy: one main matter of interest of the hardware-based secure services community group members is how to protect key usage considering the special use case where the credentials are used outside their issuing origin. For example: Suppose that a domain foo.com issues a key. Because the key is not accessible by Javascript API from another domain, we have to design a secure system where the domain bar.com is allowed to use this key.</p>
<p>There is a need for multiple domain key usage, but that this work will be treated later or when the CG will be a WG.</p>
<p>In this document, we assume that:</p>
<ul>
<li>pre-existing keys and X509 certificates are under the full control of the end-user</li>
<li>any API issued key MUST only be managed and used by its own origin</li>
</ul>
<p><em>Position to FIDO and WebAuth standards:</em> this document is focusing on providing web developers means to
issue and use identity keys (whether they are X509 certificates or any other cryptographic model with underlying
asymmetric cryptography).
FIDO standards is related to device authentication: in the FIDO vision, it is up to the relying party
to manage the link between the credential and the identity.</p>
<p><em>Position to WebCryptoAPI standards:</em> this report includes to WebCryptoAPI so that
web developers can rely upon the same API but with a different initialization (like Java Cryptographic Engine with hardware provider).</p>
<p>The user verification method is out of scope of this specification. But it should be clear whether a key is protected by:</p>
<ul>
<li>the terminal without any user interaction (passive)</li>
<li>the user presence confirmation (presence)</li>
<li>the underlying OS user verification method like an handle to the registered fingerprint template (os)</li>
<li>a specific and private key bound with user verification method like a specific PIN or a specific fingerprint/iris template (active)</p></li>
</ul>
<p>The Relying Party should take care that:</p>
<ul>
<li>with the passive option, there won't be any effective user confirmation - it's only about device authentication</li>
<li>with the presence option there is no assurance that the right user is really behind the user-agent</li>
<li>with the os option, there is options provided by the OS manufacturer to manage real world use cases - i.e. sensor not capturing the fingerprint switching to the PIN code</li>
</ul>
<p>Only the active option will guarantee that the user with the right knowledge or biometric characteristic is behind the user-agent.</p>
<h2><span class="secno">3. </span><dfn id="sec-usecases">Use cases</dfn></h2>
<p>
Hardware based services are already used in a number of domains which are particularly vulnerable to security attacks. Those domains cover financial and telecommunication industry, government and corporate services. Hardware based technology is used in those domains in specific cases such as managing authentication of the user or of the device, capturing user consent, document signature... The following use cases describe different areas in which hardware based technology is being used today. One should read those use cases as attractive for web application scenario.
</p>
<h3><span class="secno">3.1 </span>National electronic identity for accessing public services. </h3>
<p>
As of 2016, a large number of European countries have already deployed electronic identity systems and offer their citizens access to government services such as paying tax or managing pensions. Examples of countries and associated systems are:</p>
<ul>
<li>Estonia: eEstonia</li>
<li>Belgium: eID with eService ecosystem</li>
<li>Sweden: Tax Agency card and Telia eID</li>
<li>Norway: ID-porten</li>
</ul>
<p>
All the deployed solutions are relying on middleware deployment on citizen devices. </p>
<p>
Whatever the service accessed, the citizen will be expected to own a hardware token that will carry their electronic identity. This identity (most of the time a certificate for a key pair) will be used to authenticate the user and sign some transaction he or she will be performing on the government portal. The native environment of the citizen device, or of the public service office, is able to access to the hardware token, thanks to a transport layer (USB, ISO 7816 / 14443, Bluetooth Low Energy ...).
</p>
<h3><span class="secno">3.2 </span>Financial transaction signature, with user consent</h3>
<p>The remote access to financial account, together with the electronic fund transfer are now part of citizen habits in developed countries. Most of the banks do offer in their account package this remote management service. In some conditions, usually defined by the bank, some extra security is requested to the consumer to finalize transactions. This extra security aims at improving the usual login/password security barrier. Depending on the use case, it could be either a one time password sent by SMS, or a user operation to confirm his or her presence, or a digital signature of the transaction itself. That last step requires the user to use some credentials, distributed by the bank, usually stored in a secure container, such as a hardware based token (USB token or proximity token). The data signed by the user generally includes the amount and destination of the transaction, plus additional information as desired by the bank.</p>
<h4><span class="secno">3.2.1 </span>French ecosystem</h4>
<p>
In France, a list of trusted issuing certificate authorities is maintained by the Finance Ministry. The face-to-face verification of individual identity acting on behalf of a company is managed by the certificate authorities, as is the delivery of smartcards or USB tokens.
This ecosystem is also used by the French corporate banks to manage
many regulatory related tasks and also to enforce strong authentication but also digital signature, for example to confirm the file containing the widthdrawal of the salary for a company.
Issuing authentication credential is not acceptable according to the
existing risks they are facing in terms cyber attacks: combined social engineering, phishing, stolen Transaction Account Number for multiple attack vectors: 3DSecure online payment confirmation, withdrawal...
Banks are looking to cover the transaction risk by using the right credentials for the risk, with the strongest level of authentication being used for the highest risk scenarios.
Without the capability to rely upon Secure Elements in the browser, banks currently face a major issue in being able to replace the existing identity scheme delegation which provides a strong authentication and signature credential.
</p>
<h3><span class="secno">3.3 </span>The expectation from secure services</h3>
<p>
Whatever is the envisaged use case, signing a tax payment, confirming a transaction payment, validating the signature of a document, the service needs to rely on a genuine signature and user control. Each service provider needs to have a certain flexibility in designing its security model. Nevertheless, there are some minimum common basic functions that one can find in most of the security operations. The Hardware Based secure Services Community Group identified two technical features that are used on a regular basis : the secure transaction confirmation, and the secure credential storage. It is expected that those secure services, when being implemented natively in user agents, will offer a certain level of resistance and a certain level of trustworthiness. In the following section, those features will be detailed in the form of APIs and their security merits.
</p>
<h2><span class="secno">4. </span><dfn id="sec-api">Secure transaction and secure credential storage APIs</dfn></h2>
<p>This section contains the API descriptions and the different rationale for the architecture and design choices. It covers both functionalities related to the storage and usage of credentials in a hardware based token, and the secure transaction confirmation. Those functions rely on the presence of a credential, referred to here as a key. </p>
<p>The life cycle of this key is usual : creation, usage and deletion. In the framework of this short life community group, we will take the following assumptions on the key lifecycle :</p>
<ul>
<li>the key has already been generated</li>
<li>the service using the key is an authorized service - in the framework of the SOP, it is the same service that created the key. The Community Group is in parallel also working on the definition of a mechanism to allow an entity to use some keys generated by another entity, but this requires the definition of a new type of data, associated with a specific key, and this is for future deliverable. Note : all use cases are envisaged with a pre-existing key set.</li>
</ul>
<h3><span class="secno">4.1 </span>Secure transaction interface</h3>
<p>NOTE: This subpart of the API is relying upon pre-existing keys.</p>
<h4><span class="secno">4.1.1 </span>Secure transaction API</h4>
<div class="block">
<div class="blockTitleDiv">
<span class="blockTitle">Web IDL</span>
</div>
<div class="blockContent">
<pre class="code">
<code class="idl-code">
[NoInterfaceObject]
enum UVMMode { "passive", "presence",
"os", "active" };
[Exposed=(Window,Worker)]
interface Crypto {
...
readonly attribute HWCrypto hwCrypto;
...
};
[Exposed=(Window)]
interface <dfn id="dfn-HWCrypto">HWCrypto</dfn> {
Promise<any> confirm(DOMString origin,
DOMString NRMessage,
UVMMode mode,
ArrayBuffer[] issuingAuthorities);
Promise<any> deviceAuthentication(DOMString origin,
BufferSource challenge,
ArrayBuffer[] issuingAuthorities);
Promise<any> sign(DOMString origin,
DOMString NRMessage,
BufferSource data,
UVMMode mode,
ArrayBuffer[] issuingAuthorities);
}
</code>
</pre>
</div>
</div>
<h4><span class="secno">4.1.2 </span>Secure transaction API details</h4>
<p>The secure transaction confirmation aims to give the assurance to a remote entity that a transaction is confirmed by the user. Its value relies in the fact that the requested confirmation was sent to the user, was displayed to the user with no alteration and that the user confirmed exactly what was displayed. This is the 'What You See Is What You Confirm' principle.</p>
<ul>
<li>Transaction confirmation: This operation is defined to request from the browser and underlying security capabilities to ensure that the transaction context, also called non-repudiation message, has been presented to the end-user and provide non-repudiation</li>
<li>Device authentication: This operation should be used when the relying party is trying to use a hardware key to authenticate the device without any user consent</li>
<li>Digital signature: This operation is defined to allow binary data signature.</li>
</ul>
<h4>
<span class="secno">4.1.3 </span>Data types</h4>
</h4>
<dl>
<dt id="dfn-UVMMode"><code>UVMMode</code></dt>
<dd>
The type of user verification method mode prior to the key usage for the corresponding method. The <dfn id="dfn-RecognizedUVMMode">recognized user verification modes values</dfn>
are <code>"passive"</code>, <code>"presence"</code>, <code>"active"</code> and <code>"os"</code>. <code>"passive"</code> means that the no user interaction has been done, <code>"presence"</code> means that someone confirms the operation on the device, <code>"active"</code> means that the user has been actively authenticated and <code>"os"</code> means that the confirmation relies upon the OS either through PIN, fingerprint or any other end-user verification methods. The user experience of verification (including recovery procedures) is the same as provided natively by the OS itself, which may carry its own strength or weakness.
</dd>
</dl>
<h4><span class="secno">4.1.4 </span>Methods and parameters</h4>
<h5><span class="secno">4.1.4.1 </span>The confirm method</h5>
<p>
The <dfn id="dfn-method-confirm"><code>confirm</code></dfn>
method returns a new Promise object that will display the <code>origin</code> and the
<code>NRMessage</code>, sign the hash of the <code>NRMessage</code> using
the a key issued by one of the <code>issuingAuthorities</code></a> and by verifying the user according to the <code>UVMMode</code>. It must act
as follows:
</p>
<ol>
<li>
<p>
Let <var>mode</var> be the <code>mode</code> parameter
passed to the <a href="#dfn-method-confirm">confirm</a> method.
</p>
</li>
<li>
<p>
Let <var>issuingAuthorities</var>, <var>origin</var> and <var>NRMessage</var> be the result of cloning the data
of the <code>issuingAuthorities</code>, <code>origin</code> and <code>NRMessage</code> parameters passed to the
<a href="#dfn-method-confirm">confirm</a> method respectively.
</p>
</li>
<li>
<p>
If an error occurred, return a Promise rejected with
the corresponding invalid parameter(s).
</p>
</li>
<li>
<p>
Let <var>promise</var> be a new Promise.
</p>
</li>
<li>
<p>
Return <var>promise</var> and asynchronously perform the remaining steps.
</p>
</li>
<li>
<p>
If the following steps or referenced procedures say to
<a href="#concept-throw">throw</a> an error,
reject <var>promise</var> with
the returned error and then
<a href="#terminate-the-algorithm">terminate the algorithm.</a>
</p>
</li>
<li>
<p>
The trusted UI should request the selection of a key by the user. The list proposed by the browser should rely upon those available
in the various secure elements or requests the user to add the secure element (connected or contactless) and update the list correspondingly. The list should be
filtered according to the <code>issuingAuthorities</code>: this parameter should include the array of the public keys of the issuing authorities. If this values is empty, no filtering should be applied. This step can be bypassed if the user has registered a prefered key for this origin, but then the key should be presented with the <code>NRMessage</code>. In this case, the browser should ensure that the prefered key is still acceptable in regards to the current operation <code>issuingAuthorities</code> parameter.
At this step, if the user cancels the operation or if no key match the requirements, then let throw a <a href="#dfn-AbortError">AbortError</a>.
</p>
</li>
<li>
<p>
Let present to the end-user the <code>origin</code> and the non repudiation message (<code>NRMessage</code>) and the user interface to either confirm the presence or authenticate according to the <code>UVMMode</code>.
At this step, if the user cancels the operation or if the user verification method fails too many times, then let throw a <a href="#dfn-AbortError">AbortError</a>.
</p>
</li>
<li>
<p>
Let <var>signature-nrmessage</var> be the result of performing the signature
operation with the hash of the <code>NRMessage</code>.
</p>
</li>
<li>
<p>
Resolve <var>promise</var> with <var>signature-nrmessage</var> and, if applicable, <var>key</var> the public part of key used to sign.
</p>
</li>
</ol>
<h5><span class="secno">4.1.4.2 </span>The deviceAuthentication method</h5>
<p>
The <dfn id="dfn-method-deviceAuthentication"><code>deviceAuthentication</code></dfn>
method returns a new Promise object that will sign the hash of the <code>challenge</code> using
a key issued by one of the <code>issuingAuthorities</code></a>. It must act
as follows:
</p>
<ol>
<li>
<p>
Let <var>issuingAuthorities</var> and <var>origin</var>
of the <code>issuingAuthorities</code> and <code>origin</code> parameters passed to the
<a href="#dfn-method-deviceAuthentication">deviceAuthentication</a> method respectively.
</p>
</li>
<li>
<p>
If an error occurred, return a Promise rejected with
the corresponding invalid parameter(s).
</p>
</li>
<li>
<p>
Let <var>promise</var> be a new Promise.
</p>
</li>
<li>
<p>
Return <var>promise</var> and asynchronously perform the remaining steps.
</p>
</li>
<li>
<p>
If the following steps or referenced procedures say to
<a href="#concept-throw">throw</a> an error,
reject <var>promise</var> with
the returned error and then
<a href="#terminate-the-algorithm">terminate the algorithm.</a>
</p>
</li>
<li>
<p>
Let <var>signature</var> be the result of performing the signature
operation with the hash of the <code>challenge</code>. The signature should be performed with the first key that is issued by one of the <code>issuingAuthorities</code>. The requesting SP has to ensure that the corresponding key will not require a user verification method otherwise it will throw a <a href="#dfn-AbortError">AbortError</a>.
</p>
</li>
<li>
<p>
Resolve <var>promise</var> with <var>signature</var> and, if applicable, <var>key</var> the public part of key used to sign.
</p>
</li>
</ol>
<h5><span class="secno">4.1.4.3 </span>The sign method</h5>
<p>
The <dfn id="dfn-method-sign"><code>sign</code></dfn>
method returns a new Promise object that will display the <code>origin</code> and the
<code>NRMessage</code>, sign the hash of the <code>NRMessage</code> and the hash of the <code>data</code> using
the a key issued by one of the <code>issuingAuthorities</code></a> and by verifying the user according to the <code>UVMMode</code>. It must act
as follows:
</p>
<ol>
<li>
<p>
Let <var>mode</var> be the <code>mode</code> parameter
passed to the <a href="#dfn-method-sign">sign</a> method.
</p>
</li>
<li>
<p>
Let <var>issuingAuthorities</var>, <var>origin</var>, <var>data</var> and <var>NRMessage</var> be the result of cloning the data
of the <code>issuingAuthorities</code>, <code>origin</code>, <code>data</code> and <code>NRMessage</code> parameters passed to the
<a href="#dfn-method-sign">sign</a> method respectively.
</p>
</li>
<li>
<p>
If an error occurred, return a Promise rejected with
the corresponding invalid parameter(s).
</p>
</li>
<li>
<p>
Let <var>promise</var> be a new Promise.
</p>
</li>
<li>
<p>
Return <var>promise</var> and asynchronously perform the remaining steps.
</p>
</li>
<li>
<p>
If the following steps or referenced procedures say to
<a href="#concept-throw">throw</a> an error,
reject <var>promise</var> with
the returned error and then
<a href="#terminate-the-algorithm">terminate the algorithm.</a>
</p>
</li>
<li>
<p>
The trusted UI should request the selection of a key by the user. The list proposed by the browser should rely upon those available
in the various secure elements or requests the user to add the secure element (connected or contactless) and update the list correspondingly. The list should be
filtered according to the <code>issuingAuthorities</code>: this parameter should include the array of the public keys of the issuing authorities. If this values is empty, no filtering should be applied. This step can be bypassed if the user has registered a prefered key for this origin, but then the key should be presented with the <code>NRMessage</code>. In this case, the browser should ensure that the prefered key is still acceptable in regards to the current operation <code>issuingAuthorities</code> parameter.
At this step, if the user cancels the operation or if no key match the requirements, then let throw a <a href="#dfn-AbortError">AbortError</a>.
</p>
</li>
<li>
<p>
Let present to the end-user the <code>origin</code> and the <code>NRMessage</code> and the user interface to either confirm the presence or authenticate according to the <code>UVMMode</code>.
At this step, if the user cancels the operation or if the user verification method fails too many times, then let throw a <a href="#dfn-AbortError">AbortError</a>.
</p>
</li>
<li>
<p>
Let <var>signature-nrmessage</var> be the result of performing the signature
operation with the hash of the <code>NRMessage</code> and <var>signature-data</var> be the result of performing the signature operation with the hash of the <var>data</var>.
</p>
</li>
<li>
<p>
Resolve <var>promise</var> with <var>signature-nrmessage</var> and, if applicable <var>key</var>the public part of key used to sign.
</p>
</li>
</ol>
<h4><span class="secno">4.1.5 </span>Exceptions</h4>
<p>
The methods of the <a href="#dfn-HWCrypto">HWCrypto</a> interface return errors
by rejecting the returned promise with a predefined exception defined in ECMAScript
[<a href="#ECMA-262">ECMA-262</a>] or
<a href="#dfn-DOMException">DOMException</a>. The following predefined exceptions are
used: <dfn id="dfn-TypeError">TypeError</dfn>. The following DOMException types from
[<a href="#DOM4">DOM4</a>] are used:
</p>
<table>
<tbody>
<tr>
<th>Type</th>
<th>Message (optional)</th>
</tr>
<tr>
<td><dfn id="dfn-NotSupportedError"><code>NotSupportedError</code></dfn></td>
<td>The UVMMode is not supported</td>
</tr>
<tr>
<td><dfn id="dfn-AbortError"><code>AbortError</code></dfn></td>
<td>The operation was aborted</td>
</tr>
<tr>
<td><dfn id="dfn-SyntaxError"><code>SyntaxError</code></dfn></td>
<td>A required parameter was missing or out-of-range</td>
</tr>
<tr>
<td><dfn id="dfn-UnknownError"><code>UnknownError</code></dfn></td>
<td>The operation failed for an unknown transient reason (e.g. out of memory)</td>
</tr>
<tr>
<td><dfn id="dfn-DataError"><code>DataError</code></dfn></td>
<td>Data provided to an operation does not meet requirements</td>
</tr>
<tr>
<td><dfn id="dfn-OperationError"><code>OperationError</code></dfn></td>
<td>The operation failed for an operation-specific reason</td>
</tr>
</tbody>
</table>
<p>
When this specification says to
<dfn id="concept-throw">throw</dfn> an error, the user agent must
<a href="http://heycam.github.io/webidl/#dfn-throw">throw</a> an error as described in
[<a href="#WebIDL">WebIDL</a>]. When this occurs in a sub-algorithm,
this results in termination of execution of the sub-algorithm and all ancestor algorithms
until one is reached that explicitly describes procedures for catching exceptions.
</p>
<h4><span class="secno">4.1.6 </span>Security considerations</h4>
<p>This 4.1 section covers the various usages of keys. The use cases (transaction confirmation, signature, device authentication) are not highly sensitive in terms
of transaction confidentiality, which means that standard SOP rules are considered sufficient without any need for end-to-end encryption (i.e. from SP to the Hardware Secure Device). <br/>
To avoid context swapping, it is mandatory that the non-repudiation message contains specific data for the requested
transaction with the requesting party, the purpose of the transaction and the date of the operation.</p>
<p>Assumption: for many different reasons, complex data are not the right
format to get the end-user consent and confirm her/his acknowledgment: </p>
<ul>
<li>Liability: The major reasons is that this type of API is targeting valuable transactions with liability.
And for most regulations, liability relies upon the end-user capability to understand the message and confirm it.
So only the simplest format should be considered: no color, no emphasis, no image.
</li>
<li>Technical: structured documents (XHTML, XML, RDF, PDF ...) cannot be presented in trusted UI</li>
<li>Accessibility: no image should be used</li>
</ul>
<p>So it should be:</p>
<ul>
<li>text only</li>
<li>not too short: it should give enough context information to protect against social engineering and replay attacks</li>
<li>not too long: it should be displayable on almost every end-user terminal and read by the end-user</li>
<li>scoped: it should target a particular operation (type, amount, beneficiary ...) at a particular time</li>
<li>localized (UTF-8)</li>
</ul>
<p>What it should not be:</p>
<ul>
<li>full list of terms and conditions - but it can be the operation to confirm that the end-user agree with a particular version of the terms and conditions</li>
<li>a generic operation request because it would not be scoped (i.e: "Do you confirm this signature operation ?" or "Do you want to confirm the authentication ?")</li>
</ul>
<p>
NOTE: a particular attention should be paid to UTF-8 characters support with the wide variety of similar characters.
Therefore, both the context and the data should be signed at the same time with the same key. It is then up to the relying
party to ensure that the data associated with the context are both signed and they match the initial request
The user has accepted the context (and liability may rely only on that context in regards to this cryptographic operation)
The data signature (i.e. PDF signature) is then a way to embed into the data the user consent.</p>
<p>It could occur that the binary data are altered before signature by a malware or javascript or any software attacking the user agent. in such scenario, the altered binary data would be successfully signed on the user agent side. It is up to the relying party to check that the binary data and the context received are signed with the same key. In addition, the relying party, as part of its security policy, will be able to reject any attempt to submit binary signed data if they are not provided with a valid signed context.
</p>
<p>Within this signature operation, the mode for the user verification method MUST NOT be neither <code>"passive"</code> nor <code>"presence"</code>.</p>
<h3><span class="secno">4.2 </span>Secure Credential Storage</h3>
<p>This subpart describes a JavaScript API for discovering named, origin-specific pre-provisioned cryptographic keys stored into hardware secure device to be used with the Web Cryptography API. Pre-provisioned keys are keys which have been made available to the UA by means other than the generation, derivation, importing and unwrapping functions of the Web Cryptography API. Origin-specific keys are keys that are available only to a specified origin. Named keys are identified by a name assumed to be known to the origin in question and provisioned with the key itself.</p>
<h4><span class="secno">4.2.1 </span>Secure Credential Storage API</h4>
<p>This API relies on the existing WebCrypto API and provide some additionnal features to support key naming, as proposed in WebCrypto Key Discovery note, but also defines the notion of HardwareSecureDevice which represents any form of hardware cryptographic device acting as cryptographic provider, in a similar way of what JAVA defines with its framework <a href="#JCA_REF_GUIDE">Java Cryptography Architecture (JCA)</a>, to bring new capabilities to the SubtleCrypto interface and in particular the persistent and secure storage of keys.</p>
<h5><span class="secno">4.2.1.1 </span>Window interface</h5>
<p>Window interface is enhanced to expose hardware secure device management service.</p>
<div class="block">
<div class="blockTitleDiv">
<span class="blockTitle">Web IDL</span>
</div>
<div class="blockContent">
<pre class="code">
<code class="idl-code">
[NoInterfaceObject]
interface GlobalHardwareSecureDeviceManager {
readonly attribute HardwareSecureDeviceManager hsdm;
};
Window implements GlobalHardwareSecureDeviceManager;
WorkerGlobalScope implements GlobalHardwareSecureDeviceManager;
</code>
</pre>
</div>
</div>
<h5><span class="secno">4.2.1.2 </span>HardwareSecureDeviceManager interface</h5>
<p>The HardwareSecureDeviceManager interface provides access to hardware secure devices and is the source of events notifying their presences.
The notion of presence is important because a hardware secure device may not always be fixed in the same hardware environment as the user agent (e.g. an embedded secure element or a TEE); some hardware secure devices may be shared with several user agents (e.g. smart cards or NFC cards).</p>
<div class="block">
<div class="blockTitleDiv">
<span class="blockTitle">Web IDL</span>
</div>
<div class="blockContent">
<pre class="code">
<code class="idl-code">
[Exposed=(Window,Worker)]
interface HardwareSecureDeviceManager : EventTarget {
readonly attribute HardwareSecureDevice[] hardwaresecuredevices;
attribute EventHandler? onHardwareSecureDevicePresent;
attribute EventHandler? onHardwareSecureDeviceRemoval;
};
</code>
</pre>
</div>
</div>
<p>The attribute hardwaresecuredevices represents the list of hardware secure devices present and acccessible by UA at the time the attribute is accessed. UA is in charge to add or remove element in that array depending of the evolution of the environment in term of presence and absence of hardware secure device. User MAY define two event listeners (onHardwareSecureDevicePresent and onHardwareSecureDeviceRemoval) which will be called by UA to notify the user of the ongoing changes of the environment in term of presence or absence of hardware secure device.</p>
<h5><span class="secno">4.2.1.3 </span>HardwareSecureDevice interface</span></h5>
<p>The HardwareSecureDevice interface extends the SubtleCrypto interface providing a different implementation of one or more SubtleCrypto methods in order to let the hardware device handle the cryptographic operation internaly instead of the UA in software.
It can be viewed as a cryptographic provider bringing cryptographic capabilities of a hardware device to the WebCrypto API in a transparent manner.
UA MAY defines other classes extending the HardwareSecureDevice one representing different types of hardware secure device with specific implementation. One implementation COULD be using PKCS#11 as transport layer to communicate with a compatible hardware secure devices</p>
<div class="block">
<div class="blockTitleDiv">
<span class="blockTitle">Web IDL</span>
</div>
<div class="blockContent">
<pre class="code">
<code class="idl-code">
[Exposed=(Window,Worker)]
interface HardwareSecureDevice : SubtleCrypto {
readonly attribute DOMString name;
readonly attribute boolean ispresent;
};
</code>
</pre>
</div>
</div>
<p>The attribute name is used to identify in a human readable way the hardware secure device. It will typically be used by the browser when requesting permission to the user to access a given hardware secure device. The attribute ispresent is used by UA to indicate if the given hardware secure device is currently accessible. This attribute will typically be checked by UA before trying to perform any cryptographic operation on the hardware secure device.</p>
<h5><span class="secno">4.2.1.4 </span>CryptoKey interface</span></h5>
<p>The CryptoKey interface as defined in the WebCrypto Key Discovery note requires some modification in order to support hardware secure device. The CryptoKey interface and in particular the method getKeyByName is improved to add an optional parameter of hardwaresecuredevice type. If this parameter is provided, the look up for a key with the given name MUST occur only in the targeted hardware secure device. Prior to that, UA MUST validate the presence of the targeted hardware secure device first and then UA MUST call the same method than the callee one but on the provided hardware secure device object. The remaining executive flow remains unchanged as defined in WebCrypto API. In case of absence UA MUST throw an exception by using the reject promise. If the optional parameter is not provided, the search MUST occur only in software wherever the keys are usually stored by UA.</p>
<div class="block">
<div class="blockTitleDiv">
<span class="blockTitle">Web IDL</span>
</div>
<div class="blockContent">
<pre class="code">
<code class="idl-code">
[NoInterfaceObject]
interface CryptoKeys {
Promise getKeyByName (DOMString name,
optional HardwareSecureDevice hsd);
};
</code>
</pre>
</div>
</div>
<h5><span class="secno">4.2.1.5 </span>SubtleCrypto interface</span></h5>
<p>The SubtleCrypto interface as defined in the WebCrypto API requires some modification in order to support hardware secure device. All the methods of the SubtleCrypto interface are improved to add an optional parameter of hardwaresecuredevice type. If this parameter is provided, the cryptographic operation MUST occur in the targeted hardware secure device. Prior to that, UA MUST validate the presence of the targeted hardware secure device first and and then UA MUST call the same method than the callee one but on the provided hardware secure device object. The remaining executive flow remains unchanged as defined in WebCrypto API. In case of absence UA MUST throw an exception by using the reject promise. If the optional parameter is not provided, the cryptographic operation MUST occur only in software with the default UA implementation.</p>
<div class="block">
<div class="blockTitleDiv">
<span class="blockTitle">Web IDL</span>
</div>
<div class="blockContent">
<pre class="code">
<code class="idl-code">
[Exposed=(Window,Worker)]
interface SubtleCrypto {
Promise<any> encrypt(AlgorithmIdentifier algorithm,
CryptoKey key,
BufferSource data
optional HardwareSecureDevice hsd);
Promise<any> decrypt(AlgorithmIdentifier algorithm,
CryptoKey key,
BufferSource data
optional HardwareSecureDevice hsd);
Promise<any> sign(AlgorithmIdentifier algorithm,
CryptoKey key,
BufferSource data
optional HardwareSecureDevice hsd);
Promise<any> verify(AlgorithmIdentifier algorithm,
CryptoKey key,
BufferSource signature,
BufferSource data
optional HardwareSecureDevice hsd);
Promise<any> digest(AlgorithmIdentifier algorithm,
BufferSource data
optional HardwareSecureDevice hsd);
Promise<any> generateKey(AlgorithmIdentifier algorithm,
boolean extractable,
sequence<KeyUsage> keyUsages
optional HardwareSecureDevice hsd);
Promise<any> deriveKey(AlgorithmIdentifier algorithm,
CryptoKey baseKey,
AlgorithmIdentifier derivedKeyType,
boolean extractable,
sequence<KeyUsage> keyUsages
optional HardwareSecureDevice hsd);
Promise<any> deriveBits(AlgorithmIdentifier algorithm,
CryptoKey baseKey,
unsigned long length
optional HardwareSecureDevice hsd);
Promise<any> importKey(KeyFormat format,
(BufferSource or JsonWebKey) keyData,
AlgorithmIdentifier algorithm,
boolean extractable,
sequence<KeyUsage> keyUsages
optional HardwareSecureDevice hsd);
Promise<any> exportKey(KeyFormat format,
CryptoKey key
optional HardwareSecureDevice hsd);
Promise<any> wrapKey(KeyFormat format,
CryptoKey key,
CryptoKey wrappingKey,
AlgorithmIdentifier wrapAlgorithm
optional HardwareSecureDevice hsd);
Promise<any> unwrapKey(KeyFormat format,
BufferSource wrappedKey,
CryptoKey unwrappingKey,
AlgorithmIdentifier unwrapAlgorithm,
AlgorithmIdentifier unwrappedKeyAlgorithm,
boolean extractable,
sequence<KeyUsage> keyUsages
optional HardwareSecureDevice hsd);
};
</code>
</pre>
</div>
</div>
<h4><span class="secno">4.2.2 </span>Permission</span></h4>
<p>UA MUST not start to exchange with an Hardware Secure Device without the express permission of the user. UA MUST acquire permission through a user interface, unless they have prearranged trust relationships with users. The user interface MUST include the host component of the document's URI and a reminder of the Hardware Secure Device name targetted. Those permissions that are acquired through the user interface and that are preserved beyond the current browsing session (i.e. beyond the time when the browsing context is navigated to another URL) must be revocable and UA MUST respect revoked permissions.</p>
<p>Some Hardware Secure Device MAY require to be unlocked, using a secure mechanism, before being accessed. In that case, UA MUST provide a way to unlock through a user interface with input capability (text value, fingerprint...). The user interface MUST include the host component of the document's URI and a reminder of the Hardware Secure Device name targeted. The data used to unlock the Hardware Secure Device MUST be transmitted in a secure way and UA MUST NOT store those data.</p>
<h2><span class="secno">5. </span><dfn id="sec-implementation">Implementation requirements</dfn></h2>
<p>These requirements are provided to split the responsibilities of each vendor / software providers for the different implementation environments </p>
<h3><span class="secno">5.1 </span>Attestations</h3>
<p>
Both the Secure Element and the TrustedUI should be securely identified
by attestation. These attestations should be implemented as exposed in the the <a href="#FIDO20_ATTESTATIONS">FIDO 2.0 Attestations</a>.
</p>
<h3><span class="secno">5.2 </span>PC-like environments</h3>
<p>It is typically the environment where secure elements - either smartcards with readers or usb tokens - are used
with middleware through PKCS#11 or Microsoft Minidriver. In this architecture, the trusted UI is:</p>
<ul>
<li>Either the middleware when the signature is requested through PKCS#11 library</li>
<li>Or the Microsoft Windows operating system which manage the secure element user interface for CSP/CNG API</li>
</ul>
<p>In this implementation, it means that the origin of the request and the non repudiation message
should be displayed by the middleware or the Windows OS in a trusted way. </p>
<p>To limit the capability of a website to request the usage of the cryptographic API,
browser implementers SHOULD support a mechanism of white / black lists of
authorized domains (like camera access), so that an end-user could reject
any request from an unknown origin.
</p>
<p>
NOTE: transaction confirmation could be supported by providing the merge of the origin and the
non repudiation message as the data to sign for existing API. It MUST be displayed to the end-user with the user verification method input.
But signature operation will require a interface definition new method for both PKCS#11 and CSP/CNG
</p>
<h3><span class="secno">5.3 </span>Mobile environments</h3>
<p>In mobile environments, Secure Elements are either:</p>
<ul>
<li>device binded like embedded Secure Element</li>
<li>roaming like SIM or external NFC/BLE factors</li>
</ul>
<p>
But there is no capability to add middleware. It is up the OS manufacturer to provide support for the
Secure Elements and provide an API for third party applications including browsers.
</p>
<h4><span class="secno">5.3.1 </span>Generic mobile environments</h4>
<p>
In this situation, the trusted user interface should be part of the Operating System, interacting with the Secure Element
</p>
<h4><span class="secno">5.3.2 </span>Mobile environments with Trusted Execution Environment</h4>
<p>
In this situation, the browser is a trusted app and the trusted UI is relying upon the existing
TEE functions (See [GP_TEE])
</p>
<h3><span class="secno">5.4 </span>About implementations considerations</h3>
<p>Implementation into a mobile phone will require:</p>
<ul>
<li>browser modifications to interact with TEE</li>
<li>a trusted application interacting with the Secure Element</li>
</ul>
<h2><span class="secno">6. </span><dfn id="sec-todo">TODO</dfn></h2>
<p>The following topics need to be managed later:</p>
<ul>
<li>Attestation retrieval by the issuing authority to evaluate the environment (TrustedUI & SE)</li>
<li>Post issuance of the key: a specific operation should be added to the Secure Credential Storage API for two reasons: filtering the certified public keys to match the one accepted by the service provider and adding the certified public key during transaction confirmation, device authentication or signature</li>
<li>Need to confirm is this API being operated only in the context of <a href="ttps://www.w3.org/TR/secure-contexts/">Priviledged Context</a> or not</li>
</ul>
<div id="dependencies" class="section">
<h2><span class="secno">7. </span><dfn id="sec-dependencies">Dependencies</dfn></h2>
<p>This report relies on underlying specifications.</p>
<dl>
<dt>DOM</dt>
<dd>
<p>
A <a href="#dfn-conforming-implementation">conforming user agent</a> MUST support at
least the subset of the functionality defined in DOM4 that this specification relies
upon; in particular, it MUST support <code>Promises</code> and
<dfn id="dfn-DOMException">DOMException</dfn>.
[<a href="#DOM4">DOM4</a>]
</p>
</dd>
<dt>HTML</dt>
<dd>
<p>
A <a href="#dfn-conforming-implementation">conforming user agent</a> MUST support at
least the subset of the functionality defined in HTML that this specification relies
upon; in particular, it MUST support the
<a href="#dfn-ArrayBufferView">ArrayBufferView</a> typedef and the
<a href="#dfn-structured-clone">structured clone</a> algorithm.
[<a href="#HTML">HTML</a>]
</p>
</dd>
<dt>Web IDL</dt>
<dd>
<p>
A <a href="#dfn-conforming-implementation">conforming user agent</a> MUST be a
conforming implementation of the IDL fragments in this specification, as described in
the Web IDL specification. [<a href="#WebIDL">WebIDL</a>]
</p>
</dd>
</dl>
</div>
<h2><span class="secno">A. </span><dfn id="sec-references">References</dfn></h2>
<h3><span class="secno">A.1 </span>Normative references</h3>
<dl>
<dt id="DOM4">DOM4</dt>
<dd>
<cite><a href="http://www.w3.org/TR/dom/">W3C DOM4</a></cite>,
A. van Kesteren, A. Gregor, Ms2ger, Alex Russell, Robin Berjon. W3C.
<div class="ednote"><div class="ednoteHeader">Editorial note</div>A reference will be added to ECMAScript 6 once "Promises" are stable.</div>
</dd>
<dt id="ECMA-262">ECMA262</dt>
<dd>
<cite><a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">
ECMAScript 5th Edition</a></cite>, A. Wirfs-Brock, P. Lakshman et al.
</dd>
<dt id="WebCryptoAPI">WebCryptoAPI</dt>
<dd>
<cite><a href="https://www.w3.org/TR/WebCryptoAPI/">W3C WebCryptoAPI</a></cite>, Ryan Sleevi, Mark Watson. W3C.
</dd>
<dt id="WebCryptoAPI">WebCrypto Key Discovery</dt>
<dd>
<cite><a href="https://www.w3.org/TR/webcrypto-key-discovery/">W3C WebCrypto Key Discovery Note</a></cite>, Mark Watson. W3C.
</dd>
<h3><span class="secno">A.2 </span>Informative references</h3>
<dl>
<dt id="CryptoAPI">CryptoAPI</dt>
<dd>
<cite><a href="http://msdn.microsoft.com/en-us/library/aa380256.aspx">Cryptography Reference</a></cite>, Microsoft Corporation.
</dd>
<dt id="OPENTEE">OpenTEE</dt>
<dd>
<cite><a href="https://github.com/Open-TEE/project">OpenTEE project</a></cite>.
</dd>
<dt id="PKCS11">PKCS#11</dt>
<dd>
<cite><a href="https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-11-cryptographic-token-interface-standard.htm">PKCS #11: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD</a></cite>, RSA Laboratories/EMC.
</dd>
<dt id="PCSC">PC/SC</dt>
<dd>
<cite><a href="http://www.pcscworkgroup.com/">PCSC, standard for integrating smart cards and smart card readers</a></cite>, PC/SC Workgroup.
</dd>
<dt id="CryptoAPI">Replacement for <keygen></dt>
<dd>
<cite><a href="https://w3ctag.github.io/client-certificates/">Keygen and Client Certificates</a></cite>, W3C TAG.
</dd>
<dt id="GP_TEE">Trusted Execution Environment</dt>
<dd>
<cite><a href="http://www.globalplatform.org/specificationsdevice.asp">Trusted Execution Environment</a></cite>, Global Platform.
</dd>
<dt id="FIDO20_ATTESTATIONS">FIDO 2.0 Attestations</dt>
<dd>
<cite><a href="https://www.w3.org/Submission/2015/SUBM-fido-key-attestation-20151120/">FIDO 2.0: Key Attestation Format</a></cite>, W3C WebAuth.
</dd>
<dt id="JCA_REF_GUIDE">JCA Reference Guide</dt>
<dd>
<cite><a href="http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html#Introduction"> Java Cryptography Architecture (JCA) Reference Guide</a></cite>, Oracle.
</dd>
</dl>
</body>
</html>