forked from w3c/wot-thing-description
/
report.html
6097 lines (5775 loc) · 275 KB
/
report.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
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html><html lang="en"><head>
<base href="../index.html">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Web of Things (WoT) Thing Description: Implementation ReportWeb of Things (WoT) Thing Description</title>
<style type="text/css" xml:space="preserve">
/*<![CDATA[*/
body {
margin-left: 4%;
margin-right: 3%;
}
table {
border: black;
border-width: 1px;
}
h2 { font-size: 150% }
h3 { font-size: 120%; font-weight: bold }
h4 { font-size: 110%; font-weight: bold}
.tocline { list-style: none; }
th { background-color: rgb(180,255,180) }
th.rotate {
/* adjust as necessary... */
height: 180px;
white-space: nowrap;
}
th.rotate>div {
transform:
/* translate(25px, 51px)
rotate(315deg);
*/
rotate(90deg);
width: 30px;
}
th.rotate>div>span {
/* border-bottom: 1px solid #ccc;
*/
padding: 5px 10px;
}
td.baseassertion { background-color: rgb(234,255,234) }
td.tabassertion { background-color: rgb(234,255,255) }
td.defassertion { background-color: rgb(255,255,234) }
td.extraassertion { background-color: rgb(200,200,255) }
td.atrisk {
/* background-color: rgb(255,200,255) */
background-color: yellow
}
td.failed { background-color: rgb(255,200,200) }
td.passed { background-color: rgb(128,255,128) }
td.secure { background-color: rgb(0,255,0) }
td.missing { background-color: rgb(255,100,100) }
.comment {color: green; font-style: italic}
.remove {text-decoration: line-through;color: black;}
.new { color: red; }
.working {background-color: rgb(255,234,234); padding:0.2em;}
.fill-in {background-color: rgb(255,234,234);}
pre.example {
font-family: "Courier New", monospace;
white-space: pre;
background-color: rgb(204,204,255);
padding: 0.5em;
border: none;
border-width: 0;
margin-left: 0;
font-size: 100%;
width: 100%;
}
table { background-color: rgb(180,180,180) }
table.testlist {
border: black;
border-width: 1px;
}
table.grammars th, table.commands th, able.attrs th, table.testlist th {
background-color: rgb(180,255,180);
font-size: 10pt;
vertical-align: top; text-align: left;
}
table.grammars td, table.commands td, table.attrs td, table.testlist td {
/* background-color: rgb(234,255,234);
*/
font-size: 10pt;
vertical-align: top; text-align: left;
}
table.attrs {margin-top: 5px}
/*]]>*/
</style>
<link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/general.css">
<style type="text/css">
.at-risk {background-color: yellow;}
</style>
</head>
<body>
<div class="head">
<a href="http://www.w3.org/" shape="rect">
<img src="http://www.w3.org/Icons/w3c_home" alt="W3C" width="72" height="48">
</a>
<h1 id="h_ir">
Web of Things (WoT) Thing Description:<br>
Implementation Report
</h1>
<p>
<b>Version</b>: 27 March 2019</p>
<p>
<b>Contributors</b>:<br>
</p>
<p>
Sebastian Kaebisch (Siemens AG) (Editor in Chief)<br>
Takuki Kamiya (Fujitsu Laboratories of America, Inc.)<br>
Michael McCool (Intel K.K. (Japan))
</p>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2018 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
<hr title="Separator for header">
</div>
<h2 id="h_toc">
<a id="toc" shape="rect" name="toc">Table of Contents</a>
</h2>
<ul>
<li class="tocline">1. <a href="testing/report.html#intro" shape="rect">Introduction</a>
<ul>
<li class="tocline">1.1 <a href="testing/report.html#objectives" shape="rect">Implementation report objectives</a></li>
<li class="tocline">1.2 <a href="testing/report.html#non_objectives" shape="rect">Implementation report non-objectives</a></li>
</ul>
</li>
<li class="tocline">2. <a href="testing/report.html#cr_work" shape="rect">Work during the Candidate Recommendation period</a></li>
<li class="tocline">3. <a href="testing/report.html#participate" shape="rect">Participating in the implementation report</a></li>
<li class="tocline">4. <a href="testing/report.html#pr_entrance_crit" shape="rect">Entrance criteria for the Proposed Recommendation phase</a></li>
<li class="tocline">5. <a href="testing/report.html#report_reqs" shape="rect">Implementation report requirements</a>
<ul>
<li class="tocline">5.1 <a href="testing/report.html#DetailedReqs" shape="rect">Detailed requirements for implementation report</a></li>
<li class="tocline">5.2 <a href="testing/report.html#NotesOnTesting" shape="rect">Notes on testing</a></li>
<li class="tocline">5.3 <a href="testing/report.html#out_of_scope" shape="rect">Out of scope</a></li>
</ul>
</li>
<li class="tocline">6. <a href="testing/report.html#systems-toc" shape="rect">Systems</a></li>
<ul id="systems-toc">
<!--
<li class="tocline">6.x <a href="testing/report.html#impl-ORG" shape="rect">ORG</a></li>
-->
<li class="tocline">
6.1 <a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#impl-smartthings" shape="rect">SmartThings</a></li>
<li class="tocline">
6.2 <a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#impl-ercim" shape="rect">W3C/ERCIM</a></li>
<li class="tocline">
6.3 <a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#impl-hitachi" shape="rect">Hitachi, Ltd.</a></li>
<li class="tocline">
6.4 <a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#impl-intel" shape="rect">Intel Corporation</a></li>
<li class="tocline">
6.5 <a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#impl-oracle" shape="rect">Oracle Corporation</a></li>
<li class="tocline">
6.6 <a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#impl-panasonic" shape="rect">Panasonic Corporation</a></li>
<li class="tocline">
6.7 <a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#impl-siemens" shape="rect">Siemens AG</a></li>
</ul>
<li class="tocline">7. <a href="testing/report.html#security" shape="rect">Security</a></li>
<li class="tocline">8. <a href="testing/report.html#test_class" shape="rect">Test results</a>
<ul>
<li class="tocline">8.1 <a href="testing/report.html#test_assertions" shape="rect">Test assertion results</a></li>
<!--
<li class="tocline">8.2 <a href="testing/report.html#test_interop" shape="rect">Interoperability results</a></li>
-->
</ul>
</li>
<li class="tocline">
<a href="testing/report.html#appendices" shape="rect">Appendices</a>
<ul>
<!--
<li class="tocline"><a href="testing/report.html#testspecB" shape="rect">Test specifications</a></li>
-->
<li class="tocline"><a href="testing/report.html#ackB" shape="rect">Acknowledgements</a></li>
</ul>
</li>
</ul>
<h2 id="h_intro"><a id="intro" name="intro">1. Introduction</a> </h2>
<p>The <a href="http://www.w3.org/TR/wot/td">Web of Things (WoT) Thing Description Specification</a>
plans to enter the Candidate Recommendation period in April 2019.</p>
<p> The planned date for entering Proposed Recommendation is May 2019.
This document
summarizes the results from the Web of Things (WoT) TD implementation reports received and
describes the process that the Web of Things (WoT) Working Group followed in preparing the report.</p>
<h4 id="h_objectives"><a id="objectives" name="objectives">1.1 Implementation report objectives</a></h4>
<ol>
<li>Must verify that the specification is implementable.</li>
</ol>
<h4 id="h_non_objectives"><a id="non_objectives" name="non_objectives">1.2 Implementation report non-objectives</a></h4>
<ol>
<li>The IR does not attempt conformance testing of implementations.</li>
</ol>
<h2 id="h_cr_work"><a id="cr_work" name="cr_work">2. Work during the Candidate Recommendation period</a></h2>
<p>During the CR period, the Working Group carried out the following activities:</p>
<ol>
<li>Clarification and improvement of the exposition of the specification<br></li>
<li>Disposing of comments that were communicated to the WG during the CR period.
These comments and their resolution are detailed in the
<a href="http://www.w3.org/TR/2019/PR-xxx/disp.html">Disposition of Comments</a>
document for the CR period.</li>
<li>Preparation of this Implementation Report.</li>
</ol>
<h2 id="h_participate"><a id="participate" name="participate">3. Participating in the implementation report</a></h2>
<p>Implementors were invited to contribute to the assessment of the W3C Web of Things (WoT)
Thing Description Specification by submitting implementation reports describing the
coverage of their implementations with respect to the test assertions outlined
in the <a href="testing/report.html#test_assertions" shape="rect">table below</a>.</p>
<p>Implementation reports, comments on this document, or requests made for
further information were posted to the Working Group's public
mailing list <a href="mailto:wot-wg@w3.org">wot-wg@w3.org</a>
(<a href="http://lists.w3.org/Archives/Public/www-wot/">archive</a>)
and as issues on the github repository i
<a href="https://github.com/w3c/wot-thing-description">https://github.com/w3c/wot-thing-description</a>.</p>
<h2 id="h_pr_entrance_crit"><a id="pr_entrance_crit" name="pr_entrance_crit">
4. Entrance criteria for the Proposed Recommendation phase</a></h2>
<p>The Web of Things (WoT) Working Group established the following
entrance criteria for the Proposed Recommendation phase in the
Request for CR:</p>
<ol>
<li>Sufficient reports of implementation experience have been
gathered to demonstrate that Things can be described by Thing Descriptions
in sufficient detail to allow interoperabilty.</li>
<li>Specific Implementation Report Requirements (<a href="testing/report.html#report_reqs">outlined below</a>) have been met.</li>
<li>The Working Group has formally addressed and responded to all
public comments received by the Working Group.</li>
</ol>
<p>All three of these criteria have been met.
<!-- Hard to count since some implementations have multiple components, and some are shared. Omit.
A total of N implementations were documented by M different organizations.
-->
The testimonials below indicate the broad base of support
for the specification. All of the required features had at least
two implementations.
All of the optional features received at least two implementations.
However, these optional features do not have
conformance requirements that have an impact on interoperability. </p>
<h2 id="h_report_reqs"><a id="report_reqs" name="report_reqs">5. Implementation report requirements</a></h2>
<h4 id="h_DetailedReqs">
<a id="DetailedReqs" shape="rect" name="DetailedReqs">5.1 Detailed requirements for implementation report</a></h4>
<ol>
<li>Testimonials from implementers are included in the IR when
provided to document the utility and implementability of the
specification.</li>
<li>IR must cover all specified features in the specification. For
each feature the IR should indicate:
<ul>
<li>Feature status: required, optional, other.</li>
<li>Feature utility/usefulness based on feedback from
implementers.</li>
<li>Implementability of the feature specification.</li>
</ul>
</li>
<li>Feature status is a factor in test coverage in the report:
<ul>
<li>Required specification features must have at least two
implementations. Implementations that do not implement a required
specification feature must document the reason for not implementing
the feature.</li>
<li>Optional specification features must have at least one
implementation. Implementations that do not implement an optional specification
feature should document the reason for not implementing the
feature. </li>
</ul>
</li>
</ol>
<div>
<h4 id="h_NotesOnTesting"><a id="NotesOnTesting" name="NotesOnTesting">5.2 Notes on testing</a></h4>
<ol>
<li>A implementation report must indicate the outcome of evaluating
the implementation with respect to each of the test assertions. Possible
outcomes are "<code>pass</code>", "<code>fail</code>" or
"<code>not-impl</code>". "</li>
</ol>
</div>
<h4 id="h_out_of_scope"><a id="out_of_scope" name="out_of_scope">5.3 Out of scope</a></h4>
<div style="margin-left: 2em;">
<p>This implementation Report will not cover:</p>
<ul>
<li>Combinations of protocols and security schemes not listed in
<a href="http://www.w3.org/TR/wot-security-best-practices">Web of Things (WoT) Security Best Practices</a>.
</li>
</ul>
</div>
<a id="test-systems" name="test-systems"></a>
<h2 id="h_systems"><a id="test-systems" name="test-systems"></a>
<a id="systems" name="systems">6. Systems</a></h2>
<p>This section contains descriptions of each of the implementations
of the WoT Thing Description specification
from all organizations that submitted implementation reports.
Each implementation represents a working system
that either exposes or consumes at least one WoT Thing Description.
Implementations that expose a Thing Description act as a network
server with an interface as described in the Thing Description it exposes.
Implementations that consume a Thing Description act as a network
client and issue network requests consistent with the target Thing Description.
In some cases a given implementation may be used for multiple Things
and a single Thing may also act as both client and server on
multiple interfaces.
</p><p>
We only count systems with mostly independent code bases
as distinct implementations.
There are however some cases (documented in the following) where
implementations shared components but were still considered substantially
independent implementations. In cases where a substantial component
was shared across implementations the features supported by that
component were only counted once.
</p>
<div class="working" id="systems-impl">
<!-- system implementation descriptions will be inserted here -->
<div class="impl" id="impl-smartthings">
<h3>SmartThings</h3>
<p>Three implementations were created, all of which are TD Producers and
demonstrate how existing ecosystems can be supported.
</p>
<h4 id="impl-SmartThings-1">Implementation 1: TD Producer</h4>
<p><em>TD which exposes a dimmable light on the Philips Hue hub.</em></p>
<h4 id="impl-SmartThings-2">Implementation 2: TD Producer</h4>
<p><em>TD which exposes a dimmable, color control, light on the IKEA Tradfri hub.</em></p>
<h4 id="impl-SmartThings-3">Implementation 3: TD Producer</h4>
<p><em>TD which exposes a Motion sensor and Illuminance sensor supported by Node-Red.</em></p>
</div><div class="impl" id="impl-ercim">
<h3>W3C/ERCIM</h3>
<p><a href="https://github.com/draggett/arena-webhub">Arena Web Hub</a>
is an open source node-based application server for the Web of Things
that has been implemented with support from the European Commission for the
<a href="https://www.f-interop.eu">F-Interop project</a>
as a means to demonstrate high level interoperability testing for the Web of Things.</p>
<p>One of the example applications is a browser-based test suite for both client and server
in respect to the contract implied by a Thing Description.
This uses a specially designed Thing Description,
together with associated client and server applications,
and has been developed to cover the constraints implied by
the data schemas defined by the Thing Description specification.</p>
<h4 id="impl-ercim-arena-client">Arena Client: TD Consumer</h4>
<p>This is a browser-based JavaScript library designed to support multiple server platforms,
including the Arena Web Hub, Eclipse ThingWeb (node-wot), and Mozilla's Things Gateway.</p>
<h4 id="impl-ercim-arena-webhub">Arena WebHub: TD Producer</h4>
<p>Arena Web Hub is a secure by design application server with support for HTTPS and WebSockets.
HTTPS is used together with a bearer token for access control,
along with support for Server-Sent Events and Long Polling.
You can get or set the values of all properties in a single transaction.
The WebSockets sub-protocol is initiated via a protocol upgrade request from HTTPS,
and includes suppport for properties, actions and events.
This makes use of a RESTful request/response pattern with the same status codes as for HTTPS.
Arena has minimal dependencies on other modules and can be installed
via npm or a git clone of the open source repository.
Applications can combine the producer and consumer modules as needed.</p>
</div><div class="impl" id="impl-hitachi">
<h3>Hitachi, Ltd.</h3>
<p>Hitachi understands the importance of standardization
to make the world seamlessly connected, and strongly supports W3C's activities.</p>
<p>Hitachi expects that standardization of Web of Things enables easy integration
accross various Things and IoT platforms. We create a tool for
rapid application development using <a href="https://nodered.org/">Node-RED</a>,
called <a href="https://github.com/k-toumura/node-red-nodegen/tree/webofthings">Node generator</a>.</p>
<h4 id="impl-hitachi-nodegen">Node generator for Node-RED: TD consumer</h4>
<p>Node generator is command line tool to generate Node-RED node modules from several
various sources including Thing Description of Web of Things.
Using this tool, node developers can dramatically reduce their time
to implement Node-RED node modules.
</p>
</div><div class="impl" id="impl-intel">
<h3>Intel Corporation</h3>
<p>Intel supports this specification as it enables interoperation between devices
from different manufacturers, supporting the growth of an ecosystem of interoperating
IoT services and easing barriers to adoption.
</p>
<p>Three separate implementations were developed, all based on Node.js.
The core implementations focused on basic local network access without built-in security.
A separate project, used by all three implementations, provided security (encryption and
authentication) by means of a reverse proxy.
For the purposes of validation this reverse proxy was considered a shared component of all three implementations,
and the features it implemented were only counted once in the results.
</p>
<h4 id="impl-intel-security">Security Proxy: Shared Component</h4>
This component, shared across all implementations provided by Intel, was a reverse proxy service that provided
authentication (via various mechanisms indicated by the schemes indicated in the Thing
Description) and encrypted transport termination.
The reverse proxy service was made accessible over a secure tunnel, and depending on the circumstances,
was run in the cloud, on a gateway computer, or locally on a device.
As this component implemented the security features in all other implementations
from Intel, for the purposes of validation
these features are only recorded as being supported in a single implementation.
<p></p>
<h4 id="impl-intel-ocf">OCF Metadata Translator: TD Producer</h4>
<p>This implementation translated metadata made available by devices implemented using
the OCF standard and re-expressed that metadata in the form of WoT Thing Descriptions.
The actual network interfaces were however provided either by the OCF devices themselves
directly via CoAP, or via a CoAP/HTTP bridge developed by OCF.
The metadata
translator also had the ability to add semantic markup to the generated WoT Thing Descriptions,
using a database that related OCF Resource Types to iotschema.org capabilities.
It also had the capability to register generated TDs with directory services.
Secure interfaces (e.g. HTTPS combined with an authentication scheme) were provided
via a reverse proxy attached to the HTTP interface provided by the OCF CoAP/HTTP bridge.
</p>
<p>The OCF devices were based on the OCF Smart Home Demo and included both
real and simulated devices. Real devices used for testing included
</p><ol>
<li>ON\OFF Lights (various: MOSFET, Relay, LEDs),</li>
<li>RGB Light,</li>
<li>Potentiometer (analog input),</li>
<li>Toggle Switch,</li>
<li>Pushbutton,</li>
<li>IR Motion Sensor,</li>
<li>Illuminance Sensor, and</li>
<li>Buzzer.</li>
</ol>
There were also multiple instances of many of these devices, each given
unique identifiers.
<p></p>
<p></p>
<h4 id="impl-intel-speak">WebSpeak: TD Producer</h4>
<p>This implementation provided a service to convert text to speech. English
text set to its network interface was spoken audibily. This service was used to
test several accessibility scenarios, including automatic conversion of visible status
and event information to spoken announcements in order to support blind users.
This implementation only supported an HTTP network interface, without security.
Secure interfaces (eg HTTPS combined with an authentication scheme) were provided
via a reverse proxy attached to the HTTP interface.
The TDs for this service were generated using a template mechanism,
and the service also had the capability to automatically register these
TDs with a directory service.
</p>
<h4 id="impl-intel-camera">Simple Web Camera: TD Producer</h4>
<p>This implementation provided a service to capture still images from a camera
and provide them over its network interface. This was used to test various aspects
of actions, including support for inputs and outputs with different content types.
The service was also capaple of introspecting the parameters made available via any
particular attached video4linux camera
and made those parameters available as WoT Thing Description properties.
This implementation only supported an HTTP network interface, without security.
Secure interfaces (eg HTTPS combined with an authentication scheme) were provided
via a reverse proxy attached to the HTTP interface.
The TDs for this service were generated using a template mechanism,
and the service also had the capability to automatically register these
TDs with a directory service.
</p>
</div><div class="impl" id="impl-oracle">
<h3>Oracle Corporation</h3>
<p>
Oracle supports this specification as it enables manufacturers of IoT cloud platforms and applications
to integrate devices across multiple vendors, who describe their features and functionality in a uniform way.
This enables application scenarios that allow monitoring and control of devices from different manufacturers.
Flexible rules can be used to define alert conditions that trigger actions on devices based on sensor data from other devices.
Sensor data combined with big data analytics can be used to predict maintenance needs of devices
to prevent downtime.
</p>
<p>
A common way of describing devices grows the ecosystem of devices that can be easily integrated into
cloud platforms out of the box and thus enables creating digital twins of physical devices
for asset monitoring, production monitoring, fleet management, and the management of buildings and smart cities.
</p>
<p>
Oracle offers an IoT cloud platform that enables management of devices, messages and alerts.
This platform is complemented with applications for asset monitoring, production monitoring, fleet management
and connected workers.
This platform interoperates with WoT servients as described in the sections below.
</p>
<h4 id="impl-oracle-converters">Thing Description to Device Model Converters: TD Consumer and Producer</h4>
<p>Oracle's IoT cloud platform defines a device model abstraction that is used to describe the common
behaviour of a class of devices via properties (attributes), actions, messages and alerts.
This format is similar to the WoT thing description and thing descriptions can be converted
to device models and vice versa.<br>
Devices that are managed by the IoT cloud platform can be expose using the WoT thing description format
and devices that are described via thing descriptions can be consumed from the IoT cloud service.
Oracle provides open source implementations of converters to generate a device model from a thing description (td2dm)
and vice versa (dm2td).
</p>
<h4 id="impl-oracle-simulators">Oracle Digital Twin Simulator: TD Producer</h4>
<p>
Oracle's IoT Cloud Service includes a simulator for devices which allows to model
and test asset monitoring scenarios without having the physical device already available.
This allows experimenting with different device models and finding the right abstraction
before a device is actually manufacturered and thus reduce the implementation risk.
Various device simulations were defined:
</p><ul>
<li>HVAC</li>
<li>BluePump</li>
<li>Truck</li>
<li>Connected Car</li>
</ul>
These simulations were exposed via TDs that were generated from device models using
the converters above.
The simulator uses HTTP/REST with JSON to interact with the devices.
TD's for devices from other manufacterer were imported using the td2dm converter and
simulators were defined for the following devices:
<ul>
<li>Fujitsu's rotary beacon light</li>
<li>Intel's RGB light</li>
<li>Panasonic's air conditioner</li>
<li>Panasonic's hue light</li>
<li>Siemens Festo Plant</li>
<li>KETI environment sensor</li>
</ul>
<p></p>
<h4 id="impl-oracle-node-wot">Node-WoT with Oracle Binding: TD Consumer</h4>
<p>
Node-Wot contains a binding to Oracle's IoT Cloud Service.
The binding uses Oracle's JavaScript client library that encapsulates
Oracle's proprietary device to cloud communication protocol.
The integration allows node-wot to consume TDs for devices from other manufacturers and to read properties
and trigger actions on these devices.
</p>
<h4 id="impl-oracle-asset-monitoring">Oracle Asset Monitoring: Interoperability across Manufacturers</h4>
<p>
Oracle's Asset Monitoring application is used to define scenarios that combine devices from
different manufacturers. Flexible rules trigger actions and issue alerts based on sensor data from
other devices.<br>
In an industrial scenario that integrates devices from KETI, Fujitsu, Siemens and Intel was defined
and several rules control RGB lights, speech output, a valve and a pump based on sensor
data from different devices.
</p>
</div><div class="impl" id="impl-panasonic">
<h3>Panasonic Corporation</h3>
<p>
Panasonic supports this specification as it enables device manufacturers
to describe features and functionality of multiple devices in a uniform way.
This will make it possible to build mash-up applications easily with multiple devices
not only from single vendor but also from different vendors, which will expand the ecosystem.
</p>
<p>
Panasonic already has various IoT devices in the market and this specification is the
first candidate to be used for the directory system to discover those devices.
At the moment,
Panasonic implements two types of clients (TD consumer) as well as two types of servers (TD producer),
together with independent authentication server as a shared component, for experimental purposes.
</p>
<h4 id="impl-panasonic-authentication">Authentication Server: Shared Component</h4>
<p>This component provides authentication functionality for users who access Panasonic things (TD producers)
such as the real things or simulated things provided by other implementations.
This component supports HTTPS,
receives a predetermined userid and password via an HTTP POST method and sends back a bearer token based on JWT.
The token should be placed in the Authentication request header upon access to a Thing supporting
the `"bearer"` security scheme.
The URL and other information of this component is provided in the security
elements of the Thing Descriptions produced by Panasonic things. </p>
<h4 id="impl-panasonic-client-browser">Browser Based Client: TD Consumer</h4>
<p>This implementation is a TD Consumer which works on the Chrome browser.
This implementation reads a Thing Description from a designated URL via HTTP(S),
expands its properties, actions and events into UI form,
then allows user to read, write or observe a property value,
invoke an action,
or subscribe/unsubscribe to an event through the UI.
When the TD indicates that the thing needs a bearer token,
this implementation also supports the settting of user credentials such as userid and password
and retrieves the access token from the authentication service at the URL designated in the TD,
such as the Panasonic Authentication Server explained above.
This implementation also allows the manual addition of any HTTP headers
to the request message sent to the things.
</p>
<p>This implementation basically supports only HTTP(S) and does not support CoAP and MQTT.
For observe property and events,
this implementation supports both HTTP(S) long poll and a simple WebSocket protocol
which contains only a data value in its transaction.
This implementation only supports application/json as message body and does not support text/plain.
Since this implementation is browser based and uses Ajax,
its default mode requires support of CORS from the server exposing the Things,
unless the chrome browser is launched with the <code>--disable-web-security</code> option.
</p>
<h4 id="impl-panasonic-client-nodered">Node-RED Based Client: TD Consumer</h4>
<p>This implementation is a TD Consumer which works on Node-RED.
This implementation reads a Thing Description from a designated URL via HTTP(S) and from a local folder,
finds a specific thing according to a semantic annotation, and turns the thing on/off.
The implementation supports only HTTP(S) with `"nosec"` and `"basic"` authorization.
For MQTT and WebSockets,
this implementation needs a hard-coded URL due to the restriction of normal Node-RED.
</p>
<h4 id="impl-panasonic-server-real">WoT Server for Real Devices: TD Producer</h4>
<p>This implementation is a TD producer which is hosted on a cloud server and
connected to real things in the lab through a proprietary tunneling mechanism alike to remote and local WoT proxy.
This implementation accepts HTTP bindings with bearer token authorization issued by the
Panasonic Authentication Server explained above.
This implementation currently provides the following things:
</p><ol>
<li>Two Home Air Conditioners,</li>
<li>One robotics cleaner,</li>
<li>One set of Philips Hue Lighting and</li>
<li>Two LED bulletin boards.</li>
</ol>
This implementation is based on Apache HTTP server with plugins written in PHP. <p></p>
<h4 id="impl-panasonic-server-simulator">WoT Simulator: TD Producer</h4>
<p>This implementation is a TD producer which is hosted on a cloud server and
hosts virtual things running on the server.
This implementation accepts HTTP bindings with bearer token authorization issued by the
Panasonic Authentication Server explained above.
This implementation currently provides simulation of things such as
</p><ol>
<li>Home Air Conditioner,</li>
<li>Robotics cleaner,</li>
<li>Philips Hue Lighting and</li>
<li>Simple LED lighting.</li>
</ol>
This implementation is based on Node.js.
This implementation is portable and also can be run on a local machine such as a Raspberry Pi.
<p></p>
</div><div class="impl" id="impl-siemens">
<h3>Siemens AG</h3>
<p>
Siemens supports this specification as it allows manufacturers
to attach metadata to heterogeneous IoT devices and services in a uniform way.
The extensible model with a standardized serialization format in particular remedies interoperability challenges
with an installed base of long-lived industrial devices.
Furthermore,
this specification is a central building block for several digitalization topics such as
device onboarding,
device management,
digital twins,
and
data analytics.
</p>
<p>
Siemens commits to several open-source implementations of W3C Web of Things,
which are managed in the public Eclipse Thingweb project.
Siemens also implemented concepts of this specification in products and
aims at aligning the implementations and opening the features to customers
once this specification reaches REC status.
</p>
<h4 id="impl-siemens-node-wot">node-wot: TD Consumer and Producer</h4>
<p>
The node-wot implementation is a Node.js-based framework for WoT Servients.
It features an implementation of the WoT Scripting API to both consume TDs to instantiate Consumed Things
and produce Exposed Things that provide a TD.
The node-wot implementation supports several Protocol Bindings including
HTTP, CoAP, WebSockets, and MQTT,
with corresponding security mechanisms such as
DTLS (CoAP);
TLS (HTTP, MQTT),
Basic, Digest, and Bearer Token authentication (HTTP),
PSK (CoAP), and
username/password authentication (MQTT).
</p>
<h4 id="impl-siemens-thingweb-directory">Thingweb Directory: TD Consumer and Producer</h4>
<p>
The Thingweb Directory provides a directory service written in Java to register TDs
and look them up through queries (primarily SPARQL).
The implementation consumes TDs registered with it through a web API,
represent their metadata in a KnowledgeGraph, and (re-)produces TDs to return the results of queries.
Currently it supports HTTP and CoAP bindings.
</p>
<h4 id="impl-siemens-wot-fxui">WoT-fxUI: TD Consumer</h4>
<p>
WoT-fxUI is a generic user interface (UI) for Things based on Java with JavaFX.
It consumes TDs to render UI elements that allow human users to interact with Things.
The implementation currently supports HTTP and CoAP bindings.
</p>
</div></div>
<h2 id="h_security"><a id="security-xml" name="security-xml"></a>
<a id="security" name="security">7. Security</a></h2>
<p>
The
<a href="https://www.w3.org/TR/wot-thing-description">Web of Things (WoT) Thing Description Specification</a>
includes features to support security.
Functional aspects of assertions associated with security features are validated
in the same fashion as other functional features.
In addition, however, the
<a href="https://www.w3.org/2016/12/wot-wg-2016.html">Web of Things (WoT) WG Charter</a>
requires the development of a test plan that includes adversarial testing.
An appropriate security test plan, including a description
of how existing web service penetration testing tools can be used,
is given in
<a href="http://www.w3.org/TR/wot-security-testing">Web of Things (WoT) Security Testing Plan</a>.
</p>
<p>
Security validation is in addition to a description of more general security and privacy
considerations given in
<a href="https://www.w3.org/TR/wot-security/">Web of Things (WoT) Security and Privacy Considerations</a>
and the security and privacy considerations given in the specification
itself.
</p>
<p>
Note the WoT TD specification
is designed to support the description of existing devices
which may not be secure by current standards,
such adversarial testing will normally be limited to
security configurations following the
best-practices security configurations given
in
<!-- BEST-PRACTICES -->
<a href="http://www.w3.org/TR/wot-security-best-practices">Web of Things (WoT) Security Best Practices</a>.
for which security is an expectation.
</p>
<h2 id="h_test_class"><a id="test-results-xml" name="test-results-xml"></a>
<a id="test_class" name="test_class">8. Test results</a></h2>
<h3 id="test_assertions_h"><a id="test_assertions" name="test_assertions">8.1 Test assertion results</a></h3>
<p>The aim of this section is to describe the range of test assertions
developed for the
<a href="http://www.w3.org/TR/xxx">Web of Things (WoT) Thing Description Specification</a>
and summarize the results from the implementation
reports received in the CR period.
The table lists all assertions derived from the
<a href="http://www.w3.org/TR/xxx">Web of Things (WoT) Thing Description Specification</a>.
</p>
<ul>
<li>The <b>ID</b> column uniquely identifies the assertion.
and links to the assertion in the context of the specification.
</li>
<li>The <b>Assertion</b> column specifies the constraint which must be met.
</li>
<li>The <b>Req</b> column is a Y/N value indicating whether the test assertion is for a feature which is required.
Note however that the feature may only be required if another feature is also used, as indicated in
the <b>Context</b> column.
</li>
<li>The <b>Parent</b> column indicates another more general assertion that this one is a specialization of.
A specialization indicates a more restrictive context or provides additional detail to facilitate testing.
The more general assertion is only considered to have a "pass" status if all its required
or implmented specializations in a given implementation have a "pass" status.
</li>
<li>The <b>Context</b> column indicates that the "required" status of this feature depends on the use
of other features.
If the context is optional,
then the value of <b>Req</b> actually indicates whether the feature is required
if the indicated context exists.
</li>
<li>The <b>Result</b> column is annotated with the number of 'pass' (<b>P</b>), 'fail' (<b>F</b>), and 'not implemented' (<b>N</b>)
status results in the individual implementation reports.
</li>
<li>The <b>T</b> column indicates the total number of implementations (or implementation components in the case
of shared components) reporting a status (of any kind) on each assertion.
The totals do not sum to a consistent value since not all implementations have provided information on all
assertions.
</li>
</ul>
<p>
In the case of assertions with multiple mutually exclusive options (for example, enumerated values)
each of these options may be tested separately and the results combined.
In this case the 'pass' and 'total' values reported are the minimum value of any of the more detailed tests,
while the 'fail' and 'not implemented' values report the maximum value of any of these tests.
Since minimum and maximum value may be drawn from different detailed tests, the
sum of the 'pass', 'fail', and 'not implemented' cases may not equal the 'total'.
Instead the total represents the number of implementations for which all options were tested.
</p>
<p><span class="at-risk">
Assertions for which less than two implementations have reported a pass value are marked as
at-risk using yellow highlighting. These are considered to have insufficient implementation
experience and may be removed from the final recommendation.
</span></p>
<table id="testresults" class="testlist" summary="assertions and tests" cellspacing="2" cellpadding="2" width="100%">
<thead>
<tr>
<th>ID</th>
<th>Category</th>
<th>Assertion</th>
<th>Req</th>
<th>Parent</th>
<th>Context</th>
<th colspan="4">Results</th>
</tr>
<tr>
<th colspan="6"></th>
<th>P</th>
<th>F</th>
<th>N</th>
<th>T</th>
</tr>
</thead>
<tbody>
<!--
<tr>
<th colspan="10">Section Title</th>
</tr>
-->
<tr id="bindings-requirements-scheme" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#bindings-requirements-scheme">bindings-requirements-scheme</a></td>
<td class="baseassertion">Behavior</td>
<td class="atrisk">
Every form in a WoT Thing Description MUST follow the requirements
of the Protocol Binding indicated by the URI scheme of its
href member.
</td>
<td class="baseassertion">Y</td>
<td class="baseassertion"></td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#Form">Form</a><br>
</td>
<td class="missing">0</td>
<td class="missing">0</td>
<td class="missing">0</td>
<td class="missing">0</td></tr>
<tr id="bindings-server-accept" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#bindings-server-accept">bindings-server-accept</a></td>
<td class="baseassertion">Behavior</td>
<td class="atrisk">
Every form in a WoT Thing Description MUST accurately describe requests
(including request headers, if present) accepted by the Thing in an
interaction.
</td>
<td class="baseassertion">Y</td>
<td class="baseassertion"></td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#(Server)">(Server)</a><br>
</td>
<td class="missing">0</td>
<td class="missing">0</td>
<td class="missing">0</td>
<td class="missing">0</td></tr>
<tr id="client-data-schema" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#client-data-schema">client-data-schema</a></td>
<td class="baseassertion">Behavior</td>
<td class="baseassertion">
A WoT Thing acting as a Consumer when interacting with another target Thing
described in a WoT Thing Description MUST generate data
organized according to the data schemas given in the corresponding
interactions.
</td>
<td class="baseassertion">Y</td>
<td class="baseassertion"></td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#(Client)">(Client)</a><br>
</td>
<td class="baseassertion">4</td>
<td class="baseassertion">0</td>
<td class="baseassertion">9</td>
<td class="baseassertion">13</td></tr>
<tr id="client-data-schema-accept-extras" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#client-data-schema-accept-extras">client-data-schema-accept-extras</a></td>
<td class="baseassertion">Behavior</td>
<td class="baseassertion">
A WoT Thing acting as a Consumer when interacting with another Thing MUST accept without
error any additional data
not described in the data schemas given in the target Thing's WoT Thing Description.
</td>
<td class="baseassertion">Y</td>
<td class="baseassertion"></td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#(Client)">(Client)</a><br>
</td>
<td class="baseassertion">5</td>
<td class="baseassertion">0</td>
<td class="baseassertion">8</td>
<td class="baseassertion">13</td></tr>
<tr id="client-data-schema-no-extras" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#client-data-schema-no-extras">client-data-schema-no-extras</a></td>
<td class="baseassertion">Behavior</td>
<td class="baseassertion">
A WoT Thing acting as a Consumer when interacting with another Thing MUST NOT generate data
not described in the data schemas given in that Thing's WoT Thing Description.
</td>
<td class="baseassertion">Y</td>
<td class="baseassertion"></td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#(Client)">(Client)</a><br>
</td>
<td class="baseassertion">3</td>
<td class="failed">1</td>
<td class="baseassertion">9</td>
<td class="baseassertion">13</td></tr>
<tr id="client-uri-template" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#client-uri-template">client-uri-template</a></td>
<td class="baseassertion">Behavior</td>
<td class="baseassertion">
A WoT Thing acting as a Consumer when interacting with another Thing MUST generate URIs
according to the URI templates, base URIs, and form href parameters
given in the target Thing's WoT Thing Description.
</td>
<td class="baseassertion">Y</td>
<td class="baseassertion"></td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#(Client)">(Client)</a><br>
</td>
<td class="baseassertion">2</td>
<td class="baseassertion">0</td>
<td class="baseassertion">11</td>
<td class="baseassertion">13</td></tr>
<tr id="server-data-schema" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#server-data-schema">server-data-schema</a></td>
<td class="baseassertion">Behavior</td>
<td class="baseassertion">
A WoT Thing Description MUST accurately describe the
data returned and accepted by each interaction.
</td>
<td class="baseassertion">Y</td>
<td class="baseassertion"></td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#(Server)">(Server)</a><br>
</td>
<td class="baseassertion">7</td>
<td class="failed">1</td>
<td class="baseassertion">4</td>
<td class="baseassertion">12</td></tr>
<tr id="server-data-schema-extras" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#server-data-schema-extras">server-data-schema-extras</a></td>
<td class="baseassertion">Behavior</td>
<td class="baseassertion">
A Thing MAY return additional data from an interaction
even when such data is
not described in the data schemas given in its WoT Thing Description.
</td>
<td class="baseassertion">N</td>
<td class="baseassertion"></td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#(Server)">(Server)</a><br>
</td>
<td class="baseassertion">5</td>
<td class="baseassertion">0</td>
<td class="baseassertion">7</td>
<td class="baseassertion">12</td></tr>
<tr id="server-uri-template" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#server-uri-template">server-uri-template</a></td>
<td class="baseassertion">Behavior</td>
<td class="baseassertion">
URI templates, base URIs, and href members
in a WoT Thing Description MUST accurately describe the WoT Interace of the Thing.
</td>
<td class="baseassertion">Y</td>
<td class="baseassertion"></td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#(Server)">(Server)</a><br>
</td>
<td class="baseassertion">4</td>
<td class="baseassertion">0</td>
<td class="baseassertion">8</td>
<td class="baseassertion">12</td></tr>
<tr id="td-action-arrays" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#td-action-arrays">td-action-arrays</a></td>
<td class="baseassertion">Syntax</td>
<td class="baseassertion">
The type of the member forms
MUST be serialized as a JSON array.
</td>
<td class="baseassertion">Y</td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#td-actions">td-actions</a><br>
</td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#Action">Action</a><br>
</td>
<td class="baseassertion">10</td>
<td class="baseassertion">0</td>
<td class="baseassertion">4</td>
<td class="baseassertion">14</td></tr>
<tr id="td-action-names" class="baseassertion">
<td class="baseassertion"><a target="spec" href="#td-action-names">td-action-names</a></td>
<td class="baseassertion">Syntax</td>
<td class="atrisk">
Each optional vocabulary term
as defined in the class Action
and its superclass
InteractionAffordance
MUST be serialized as a JSON name within an Action object.
</td>
<td class="baseassertion">Y</td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#td-actions">td-actions</a><br>
</td>
<td class="baseassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#Action">Action</a><br>
</td>
<td class="failed">1</td>
<td class="baseassertion">0</td>
<td class="baseassertion">13</td>
<td class="baseassertion">14</td></tr>
<tr id="td-action-names_description" class="extraassertion">
<td class="extraassertion"><a target="spec" href="#td-action-names_description">td-action-names_description</a></td>
<td class="extraassertion">Syntax</td>
<td class="extraassertion">
The vocabulary term
description
MUST be serialized as a JSON name within an Action object.
</td>
<td class="extraassertion">Y</td>
<td class="extraassertion">
<a href="file:///home/mmccool/Dev/wot-thing-description/testing/report.html#td-action-names">td-action-names</a><br>
</td>
<td class="extraassertion">