-
Notifications
You must be signed in to change notification settings - Fork 17
/
static.html
4017 lines (3729 loc) · 299 KB
/
static.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-US"><head>
<meta charset="utf-8">
<meta name="generator" content="ReSpec 34.1.2">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<style>
span.example-title{text-transform:none}
:is(aside,div).example,div.illegal-example{padding:.5em;margin:1em 0;position:relative;clear:both}
div.illegal-example{color:red}
div.illegal-example p{color:#000}
:is(aside,div).example{border-left-width:.5em;border-left-style:solid;border-color:#e0cb52;background:#fcfaee}
aside.example div.example{border-left-width:.1em;border-color:#999;background:#fff}
.example pre{background-color:rgba(0,0,0,.03)}
</style>
<style>
.issue-label{text-transform:initial}
.warning>p:first-child{margin-top:0}
.warning{padding:.5em;border-left-width:.5em;border-left-style:solid}
span.warning{padding:.1em .5em .15em}
.issue.closed span.issue-number{text-decoration:line-through}
.issue.closed span.issue-number::after{content:" (Closed)";font-size:smaller}
.warning{border-color:#f11;border-width:.2em;border-style:solid;background:#fbe9e9}
.warning-title:before{content:"⚠";font-size:1.3em;float:left;padding-right:.3em;margin-top:-.3em}
li.task-list-item{list-style:none}
input.task-list-item-checkbox{margin:0 .35em .25em -1.6em;vertical-align:middle}
.issue a.respec-gh-label{padding:5px;margin:0 2px 0 2px;font-size:10px;text-transform:none;text-decoration:none;font-weight:700;border-radius:4px;position:relative;bottom:2px;border:none;display:inline-block}
</style>
<style>
dfn{cursor:pointer}
.dfn-panel{position:absolute;z-index:35;min-width:300px;max-width:500px;padding:.5em .75em;margin-top:.6em;font-family:"Helvetica Neue",sans-serif;font-size:small;background:#fff;color:#000;box-shadow:0 1em 3em -.4em rgba(0,0,0,.3),0 0 1px 1px rgba(0,0,0,.05);border-radius:2px}
.dfn-panel:not(.docked)>.caret{position:absolute;top:-9px}
.dfn-panel:not(.docked)>.caret::after,.dfn-panel:not(.docked)>.caret::before{content:"";position:absolute;border:10px solid transparent;border-top:0;border-bottom:10px solid #fff;top:0}
.dfn-panel:not(.docked)>.caret::before{border-bottom:9px solid #a2a9b1}
.dfn-panel *{margin:0}
.dfn-panel b{display:block;color:#000;margin-top:.25em}
.dfn-panel ul a[href]{color:#333}
.dfn-panel>div{display:flex}
.dfn-panel a.self-link{font-weight:700;margin-right:auto}
.dfn-panel .marker{padding:.1em;margin-left:.5em;border-radius:.2em;text-align:center;white-space:nowrap;font-size:90%;color:#040b1c}
.dfn-panel .marker.dfn-exported{background:#d1edfd;box-shadow:0 0 0 .125em #1ca5f940}
.dfn-panel .marker.idl-block{background:#8ccbf2;box-shadow:0 0 0 .125em #0670b161}
.dfn-panel a:not(:hover){text-decoration:none!important;border-bottom:none!important}
.dfn-panel a[href]:hover{border-bottom-width:1px}
.dfn-panel ul{padding:0}
.dfn-panel li{margin-left:1em}
.dfn-panel.docked{position:fixed;left:.5em;top:unset;bottom:2em;margin:0 auto;max-width:calc(100vw - .75em * 2 - .5em - .2em * 2);max-height:30vh;overflow:auto}
</style>
<title>Web of Things (WoT) Discovery</title>
<style type="text/css">
a[href].internalDFN {
color: inherit;
border-bottom: 1px solid #99c;
text-decoration: none;
}
img.wot-diagram {
max-width: 90%;
height: auto;
}
.rfc2119-assertion {
background-color: rgb(230,230,230)
}
</style>
<style id="respec-mainstyle">
@keyframes pop{
0%{transform:scale(1,1)}
25%{transform:scale(1.25,1.25);opacity:.75}
100%{transform:scale(1,1)}
}
:is(h1,h2,h3,h4,h5,h6,a) abbr{border:none}
dfn{font-weight:700}
a.internalDFN{color:inherit;border-bottom:1px solid #99c;text-decoration:none}
a.externalDFN{color:inherit;border-bottom:1px dotted #ccc;text-decoration:none}
a.bibref{text-decoration:none}
.respec-offending-element:target{animation:pop .25s ease-in-out 0s 1}
.respec-offending-element,a[href].respec-offending-element{text-decoration:red wavy underline}
@supports not (text-decoration:red wavy underline){
.respec-offending-element:not(pre){display:inline-block}
.respec-offending-element{background:url(data:image/gif;base64,R0lGODdhBAADAPEAANv///8AAP///wAAACwAAAAABAADAEACBZQjmIAFADs=) bottom repeat-x}
}
#references :target{background:#eaf3ff;animation:pop .4s ease-in-out 0s 1}
cite .bibref{font-style:normal}
a[href].orcid{padding-left:4px;padding-right:4px}
a[href].orcid>svg{margin-bottom:-2px}
.toc a,.tof a{text-decoration:none}
a .figno,a .secno{color:#000}
ol.tof,ul.tof{list-style:none outside none}
.caption{margin-top:.5em;font-style:italic}
table.simple{border-spacing:0;border-collapse:collapse;border-bottom:3px solid #005a9c}
.simple th{background:#005a9c;color:#fff;padding:3px 5px;text-align:left}
.simple th a{color:#fff;padding:3px 5px;text-align:left}
.simple th[scope=row]{background:inherit;color:inherit;border-top:1px solid #ddd}
.simple td{padding:3px 10px;border-top:1px solid #ddd}
.simple tr:nth-child(even){background:#f0f6ff}
.section dd>p:first-child{margin-top:0}
.section dd>p:last-child{margin-bottom:0}
.section dd{margin-bottom:1em}
.section dl.attrs dd,.section dl.eldef dd{margin-bottom:0}
#issue-summary>ul{column-count:2}
#issue-summary li{list-style:none;display:inline-block}
details.respec-tests-details{margin-left:1em;display:inline-block;vertical-align:top}
details.respec-tests-details>*{padding-right:2em}
details.respec-tests-details[open]{z-index:999999;position:absolute;border:thin solid #cad3e2;border-radius:.3em;background-color:#fff;padding-bottom:.5em}
details.respec-tests-details[open]>summary{border-bottom:thin solid #cad3e2;padding-left:1em;margin-bottom:1em;line-height:2em}
details.respec-tests-details>ul{width:100%;margin-top:-.3em}
details.respec-tests-details>li{padding-left:1em}
.self-link:hover{opacity:1;text-decoration:none;background-color:transparent}
aside.example .marker>a.self-link{color:inherit}
.header-wrapper{display:flex;align-items:baseline}
:is(h2,h3,h4,h5,h6):not(#toc>h2,#abstract>h2,#sotd>h2,.head>h2){position:relative;left:-.5em}
:is(h2,h3,h4,h5,h6):not(#toch2)+a.self-link{color:inherit;order:-1;position:relative;left:-1.1em;font-size:1rem;opacity:.5}
:is(h2,h3,h4,h5,h6)+a.self-link::before{content:"§";text-decoration:none;color:var(--heading-text)}
:is(h2,h3)+a.self-link{top:-.2em}
:is(h4,h5,h6)+a.self-link::before{color:#000}
@media (max-width:767px){
dd{margin-left:0}
}
@media print{
.removeOnSave{display:none}
}
</style>
<meta name="description" content="The W3C Web of Things (WoT) is intended to enable
interoperability across IoT platforms and application
domains. One key mechanism for accomplishing this goal
is the definition and use of metadata describing the
interactions an IoT device or service makes available
over the network at a suitable level of abstraction.
The WoT Thing Description specification satisfies this objective.">
<style>
.hljs{display:block;overflow-x:auto;padding:.5em;color:#383a42;background:#fafafa}
.hljs-comment,.hljs-quote{color:#717277;font-style:italic}
.hljs-doctag,.hljs-formula,.hljs-keyword{color:#a626a4}
.hljs-deletion,.hljs-name,.hljs-section,.hljs-selector-tag,.hljs-subst{color:#ca4706;font-weight:700}
.hljs-literal{color:#0b76c5}
.hljs-addition,.hljs-attribute,.hljs-meta-string,.hljs-regexp,.hljs-string{color:#42803c}
.hljs-built_in,.hljs-class .hljs-title{color:#9a6a01}
.hljs-attr,.hljs-number,.hljs-selector-attr,.hljs-selector-class,.hljs-selector-pseudo,.hljs-template-variable,.hljs-type,.hljs-variable{color:#986801}
.hljs-bullet,.hljs-link,.hljs-meta,.hljs-selector-id,.hljs-symbol,.hljs-title{color:#336ae3}
.hljs-emphasis{font-style:italic}
.hljs-strong{font-weight:700}
.hljs-link{text-decoration:underline}
</style>
<style>
var{position:relative;cursor:pointer}
var[data-type]::after,var[data-type]::before{position:absolute;left:50%;top:-6px;opacity:0;transition:opacity .4s;pointer-events:none}
var[data-type]::before{content:"";transform:translateX(-50%);border-width:4px 6px 0 6px;border-style:solid;border-color:transparent;border-top-color:#000}
var[data-type]::after{content:attr(data-type);transform:translateX(-50%) translateY(-100%);background:#000;text-align:center;font-family:"Dank Mono","Fira Code",monospace;font-style:normal;padding:6px;border-radius:3px;color:#daca88;text-indent:0;font-weight:400}
var[data-type]:hover::after,var[data-type]:hover::before{opacity:1}
</style>
<script id="initialUserConfig" type="application/json">{
"lint": {
"check-punctuation": true,
"local-refs-exist": true,
"no-http-props": true,
"no-headingless-sections": true,
"no-unused-dfns": false
},
"doJsonLd": true,
"noLegacyStyle": true,
"inlineCSS": true,
"noIDLIn": true,
"specStatus": "ED",
"implementationReportURI": "https://w3c.github.io/wot-discovery/testing/report.html",
"shortName": "wot-discovery",
"copyrightStart": 2017,
"group": "wg/wot",
"wgPublicList": "public-wot-wg",
"github": {
"repoURL": "https://github.com/w3c/wot-discovery",
"branch": "main"
},
"previousPublishDate": "2022-08-10",
"previousMaturity": "FPWD",
"editors": [
{
"name": "Andrea Cimmino",
"w3cid": "115672",
"company": "Universidad Politécnica de Madrid",
"companyURL": "https://www.upm.es/"
},
{
"name": "Michael McCool",
"w3cid": "93137",
"company": "Intel Corp.",
"companyURL": "https://www.intel.com/"
},
{
"name": "Farshid Tavakolizadeh",
"w3cid": "122520",
"company": "Invited Expert"
},
{
"name": "Kunihiko Toumura",
"w3cid": "83488",
"company": "Hitachi, Ltd.",
"companyURL": "https://www.hitachi.com/"
}
],
"formerEditors": [
{
"name": "Farshid Tavakolizadeh",
"w3cid": "122520",
"company": "Fraunhofer-Gesellschaft",
"companyURL": "https://www.fraunhofer.de/",
"retiredDate": "2021-09-30"
}
],
"otherLinks": [
{
"key": "Contributors",
"data": [
{
"value": "In the GitHub repository",
"href": "https://github.com/w3c/wot-discovery/graphs/contributors"
}
]
},
{
"key": "Repository",
"data": [
{
"value": "We are on GitHub",
"href": "https://github.com/w3c/wot-discovery/"
},
{
"value": "File a bug",
"href": "https://github.com/w3c/wot-discovery/issues"
}
]
}
],
"localBiblio": {
"Discovery-Categorization-IoT": {
"title": "A Categorization of Discovery Technologies for the Internet of Things",
"href": "https://dl.acm.org/doi/10.1145/2991561.2991570",
"authors": [
"Arne Broering",
"Soumya Kanti Datta",
"Christian Bonnet"
],
"date": "7-9 November 2016",
"publisher": "Association of Computing Machinery (ACM): IoT'16 Proceedings",
"id": "discovery-categorization-iot"
},
"GDPR-Defs": {
"title": "General Data Protection Regulation (GDPR) Article 4 - Definitions",
"href": "https://gdpr-info.eu/art-4-gdpr/",
"publisher": "European Union (EU) and the European Economic Area (EEA)",
"id": "gdpr-defs"
},
"OWASP-Top-10": {
"title": "OWASP Top Ten",
"href": "https://owasp.org/www-project-top-ten/",
"publisher": "OWASP",
"id": "owasp-top-10"
},
"REST-IOT": {
"title": "RESTful Design for Internet of Things Systems",
"href": "https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-rest-iot-06",
"authors": [
"Ari Keranen",
"Matthias Kovatsch",
"Klaus Hartke"
],
"publisher": "IETF",
"date": "11 May 2020",
"id": "rest-iot"
},
"JSONPATH": {
"title": "JSONPath: Query expressions for JSON",
"href": "https://datatracker.ietf.org/doc/html/draft-ietf-jsonpath-base",
"authors": [
"Stefan Gössner",
"Glyn Normington",
"Carsten Bormann"
],
"publisher": "IETF",
"status": "DRAFT",
"id": "jsonpath"
},
"wot-usecases": {
"title": "Web of Things (WoT): Use Cases",
"href": "https://w3c.github.io/wot-usecases/",
"authors": [
"Michael Lagally",
"Michael McCool",
"Ryuichi Matsukura",
"Tomoaki Mizushima"
],
"publisher": "W3C",
"date": "15 October 2020",
"status": "Editor's Draft",
"id": "wot-usecases"
},
"AMPLIFICATION-ATTACKS": {
"title": "Amplification Attacks Using the Constrained Application Protocol (CoAP)",
"href": "https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-amplification-attacks",
"authors": [
"John Preuß Mattsson",
"Göran Selander",
"Christian Amsüss"
],
"publisher": "IETF",
"status": "DRAFT",
"id": "amplification-attacks"
}
},
"publishISODate": "2023-06-09T00:00:00.000Z",
"generatedSubtitle": "W3C Editor's Draft 09 June 2023"
}</script>
<link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/2021/W3C-ED"></head>
<body class="h-entry toc-inline"><div class="head">
<p class="logos"><a class="logo" href="https://www.w3.org/"><img crossorigin="" alt="W3C" height="48" src="https://www.w3.org/StyleSheets/TR/2021/logos/W3C" width="72">
</a></p>
<h1 id="title" class="title">Web of Things (WoT) Discovery</h1>
<p id="w3c-state"><a href="https://www.w3.org/standards/types#ED">W3C Editor's Draft</a> <time class="dt-published" datetime="2023-06-09">09 June 2023</time></p>
<details open="">
<summary>More details about this document</summary>
<dl>
<dt>This version:</dt><dd>
<a class="u-url" href="https://w3c.github.io/wot-discovery/">https://w3c.github.io/wot-discovery/</a>
</dd>
<dt>Latest published version:</dt><dd>
<a href="https://www.w3.org/TR/wot-discovery/">https://www.w3.org/TR/wot-discovery/</a>
</dd>
<dt>Latest editor's draft:</dt><dd><a href="https://w3c.github.io/wot-discovery/">https://w3c.github.io/wot-discovery/</a></dd>
<dt>History:</dt><dd>
<a href="https://www.w3.org/standards/history/wot-discovery">https://www.w3.org/standards/history/wot-discovery</a>
</dd><dd>
<a href="https://github.com/w3c/wot-discovery/commits/main">Commit history</a>
</dd>
<dt>Implementation report:</dt><dd>
<a href="https://w3c.github.io/wot-discovery/testing/report.html">https://w3c.github.io/wot-discovery/testing/report.html</a>
</dd>
<dt>Editors:</dt><dd class="editor p-author h-card vcard" data-editor-id="115672">
<span class="p-name fn">Andrea Cimmino</span> (<a class="p-org org h-org" href="https://www.upm.es/">Universidad Politécnica de Madrid</a>)
</dd><dd class="editor p-author h-card vcard" data-editor-id="93137">
<span class="p-name fn">Michael McCool</span> (<a class="p-org org h-org" href="https://www.intel.com/">Intel Corp.</a>)
</dd><dd class="editor p-author h-card vcard" data-editor-id="122520">
<span class="p-name fn">Farshid Tavakolizadeh</span> (<span class="p-org org h-org">Invited Expert</span>)
</dd><dd class="editor p-author h-card vcard" data-editor-id="83488">
<span class="p-name fn">Kunihiko Toumura</span> (<a class="p-org org h-org" href="https://www.hitachi.com/">Hitachi, Ltd.</a>)
</dd>
<dt>
Former editor:
</dt><dd class="editor p-author h-card vcard" data-editor-id="122520">
<span class="p-name fn">Farshid Tavakolizadeh</span> (<a class="p-org org h-org" href="https://www.fraunhofer.de/">Fraunhofer-Gesellschaft</a>) - Until <time datetime="2021-09-30">30 September 2021</time>
</dd>
<dt>Feedback:</dt><dd>
<a href="https://github.com/w3c/wot-discovery/">GitHub w3c/wot-discovery</a>
(<a href="https://github.com/w3c/wot-discovery/pulls/">pull requests</a>,
<a href="https://github.com/w3c/wot-discovery/issues/new/choose">new issue</a>,
<a href="https://github.com/w3c/wot-discovery/issues/">open issues</a>)
</dd><dd><a href="mailto:public-wot-wg@w3.org?subject=%5Bwot-discovery%5D%20YOUR%20TOPIC%20HERE">public-wot-wg@w3.org</a> with subject line <kbd>[wot-discovery] <em>… message topic …</em></kbd> (<a rel="discussion" href="https://lists.w3.org/Archives/Public/public-wot-wg">archives</a>)</dd>
<dt>Contributors</dt><dd>
<a href="https://github.com/w3c/wot-discovery/graphs/contributors">In the GitHub repository</a>
</dd><dt>Repository</dt><dd>
<a href="https://github.com/w3c/wot-discovery/">We are on GitHub</a>
</dd><dd>
<a href="https://github.com/w3c/wot-discovery/issues">File a bug</a>
</dd>
</dl>
</details>
<p class="copyright">
<a href="https://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
©
2017-2023
<a href="https://www.w3.org/">World Wide Web Consortium</a>.
<abbr title="World Wide Web Consortium">W3C</abbr><sup>®</sup>
<a href="https://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href="https://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
<a rel="license" href="https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document" title="W3C Software and Document Notice and License">permissive document license</a> rules apply.
</p>
<hr title="Separator for header">
</div>
<section id="abstract" class="introductory"><h2>Abstract</h2>
<p>The <abbr title="World Wide Web Consortium">W3C</abbr> Web of Things (WoT) is intended to enable
interoperability across IoT platforms and application
domains. One key mechanism for accomplishing this goal
is the definition and use of metadata describing the
interactions an IoT device or service makes available
over the network at a suitable level of abstraction.
The WoT Thing Description specification satisfies this objective.
</p>
<p>However, in order to use a Thing its Thing Description
first has to be obtained. The <em>WoT Discovery</em> process described
in this document addresses this problem.
WoT Discovery needs to support the distribution of WoT Thing Descriptions
in a variety of use cases. This includes ad-hoc and engineered systems;
during development and at runtime; and on both local and global networks.
The process also needs to work with existing discovery mechanisms,
be secure, protect private information, and be able to efficiently
handle updates to WoT Thing Descriptions and the
dynamic and diverse nature of the IoT ecosystem.
</p>
<p>The WoT Discovery process is divided into two phases,
Introduction, and Exploration. The Introduction phase
leverages existing discovery mechanisms but does not directly
expose metadata; they are simply used to discover Exploration
services, which provide metadata but only after secure authentication
and authorization. This document normatively defines two Exploration
services: for distributing a single WoT Thing Description from a regular
web service, including as a special case self-description;
and a searchable WoT Thing Description Directory
service for collections of Thing Descriptions.
A variety of Introduction services are also described and where
necessary normative definitions are given to support them.
</p>
</section>
<section id="sotd" class="introductory"><h2>Status of This Document</h2><p><em>This section describes the status of this
document at the time of its publication. A list of current <abbr title="World Wide Web Consortium">W3C</abbr>
publications and the latest revision of this technical report can be found
in the <a href="https://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
https://www.w3.org/TR/.</em></p><p>
This document was published by the <a href="https://www.w3.org/groups/wg/wot">Web of Things Working Group</a> as
an Editor's Draft.
</p><p>Publication as an Editor's Draft does not
imply endorsement by <abbr title="World Wide Web Consortium">W3C</abbr> and its Members. </p><p>
This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than work in progress.
</p><p>
This document was produced by a group
operating under the
<a href="https://www.w3.org/Consortium/Patent-Policy/"><abbr title="World Wide Web Consortium">W3C</abbr> Patent
Policy</a>.
<abbr title="World Wide Web Consortium">W3C</abbr> maintains a
<a rel="disclosure" href="https://www.w3.org/groups/wg/wot/ipr">public list of any patent disclosures</a>
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent which the individual believes contains
<a href="https://www.w3.org/Consortium/Patent-Policy/#def-essential">Essential Claim(s)</a>
must disclose the information in accordance with
<a href="https://www.w3.org/Consortium/Patent-Policy/#sec-Disclosure">section 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
</p><p>
This document is governed by the
<a id="w3c_process_revision" href="https://www.w3.org/2021/Process-20211102/">2 November 2021 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
</p></section><nav id="toc"><h2 class="introductory" id="table-of-contents">Table of Contents</h2><ol class="toc"><li class="tocline"><a class="tocxref" href="#abstract">Abstract</a></li><li class="tocline"><a class="tocxref" href="#sotd">Status of This Document</a></li><li class="tocline"><a class="tocxref" href="#introduction"><bdi class="secno">1. </bdi>Introduction</a></li><li class="tocline"><a class="tocxref" href="#conformance"><bdi class="secno">2. </bdi>Conformance</a></li><li class="tocline"><a class="tocxref" href="#terminology"><bdi class="secno">3. </bdi>Terminology</a></li><li class="tocline"><a class="tocxref" href="#architecture"><bdi class="secno">4. </bdi>Architecture</a></li><li class="tocline"><a class="tocxref" href="#discoverer-process"><bdi class="secno">5. </bdi>Discoverer Process</a></li><li class="tocline"><a class="tocxref" href="#introduction-mech"><bdi class="secno">6. </bdi>Introduction Mechanisms</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#introduction-direct"><bdi class="secno">6.1 </bdi>Direct</a></li><li class="tocline"><a class="tocxref" href="#introduction-well-known"><bdi class="secno">6.2 </bdi>Well-Known URIs</a></li><li class="tocline"><a class="tocxref" href="#introduction-dns-sd-sec"><bdi class="secno">6.3 </bdi>DNS-Based Service Discovery</a></li><li class="tocline"><a class="tocxref" href="#introduction-core-rd-sec"><bdi class="secno">6.4 </bdi>CoRE Link Format and CoRE Resource Directory</a></li><li class="tocline"><a class="tocxref" href="#introduction-did-sec"><bdi class="secno">6.5 </bdi>DID Documents</a></li></ol></li><li class="tocline"><a class="tocxref" href="#exploration-mech"><bdi class="secno">7. </bdi>Exploration Mechanisms</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#exploration-overview"><bdi class="secno">7.1 </bdi>Overview</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#exploration-ontology"><bdi class="secno">7.1.1 </bdi>Ontology</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#exploration-td-type-thingdirectory"><bdi class="secno">7.1.1.1 </bdi><code>ThingDirectory</code></a></li><li class="tocline"><a class="tocxref" href="#exploration-td-type-thinglink"><bdi class="secno">7.1.1.2 </bdi><code>ThingLink</code></a></li></ol></li><li class="tocline"><a class="tocxref" href="#exploration-secboot"><bdi class="secno">7.1.2 </bdi>Security Bootstrapping</a></li></ol></li><li class="tocline"><a class="tocxref" href="#exploration-server"><bdi class="secno">7.2 </bdi>Thing Description Server</a></li><li class="tocline"><a class="tocxref" href="#exploration-directory"><bdi class="secno">7.3 </bdi>Thing Description Directory</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#exploration-directory-info"><bdi class="secno">7.3.1 </bdi>Information Model</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#exploration-directory-registration-info"><bdi class="secno">7.3.1.1 </bdi>Registration Information</a></li><li class="tocline"><a class="tocxref" href="#exploration-directory-registration-expiry"><bdi class="secno">7.3.1.2 </bdi>Registration Expiry</a></li><li class="tocline"><a class="tocxref" href="#exploration-directory-anonymous-td"><bdi class="secno">7.3.1.3 </bdi>Anonymous TD Identifiers</a></li></ol></li><li class="tocline"><a class="tocxref" href="#exploration-directory-api"><bdi class="secno">7.3.2 </bdi>Directory Service API</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#exploration-directory-api-things"><bdi class="secno">7.3.2.1 </bdi>Things API</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#exploration-directory-api-things-creation"><bdi class="secno">7.3.2.1.1 </bdi>Creation</a></li><li class="tocline"><a class="tocxref" href="#exploration-directory-api-things-retrieval"><bdi class="secno">7.3.2.1.2 </bdi>Retrieval</a></li><li class="tocline"><a class="tocxref" href="#exploration-directory-api-things-update"><bdi class="secno">7.3.2.1.3 </bdi>Update</a></li><li class="tocline"><a class="tocxref" href="#exploration-directory-api-things-deletion"><bdi class="secno">7.3.2.1.4 </bdi>Deletion</a></li><li class="tocline"><a class="tocxref" href="#exploration-directory-api-things-listing"><bdi class="secno">7.3.2.1.5 </bdi>Listing</a></li><li class="tocline"><a class="tocxref" href="#exploration-directory-api-things-validation"><bdi class="secno">7.3.2.1.6 </bdi>Validation</a></li></ol></li><li class="tocline"><a class="tocxref" href="#exploration-directory-api-notification"><bdi class="secno">7.3.2.2 </bdi>Events API</a></li><li class="tocline"><a class="tocxref" href="#exploration-directory-api-search"><bdi class="secno">7.3.2.3 </bdi>Search API</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#jsonpath-semantic"><bdi class="secno">7.3.2.3.1 </bdi>Syntactic search: JSONPath</a></li><li class="tocline"><a class="tocxref" href="#xpath-semantic"><bdi class="secno">7.3.2.3.2 </bdi>Syntactic search: XPath</a></li><li class="tocline"><a class="tocxref" href="#search-semantic"><bdi class="secno">7.3.2.3.3 </bdi>Semantic search: SPARQL</a></li></ol></li><li class="tocline"><a class="tocxref" href="#directory-api-spec"><bdi class="secno">7.3.2.4 </bdi>API Specification (Thing Model)</a></li></ol></li></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#security-considerations"><bdi class="secno">8. </bdi>Security Considerations</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#security-consideration-dos"><bdi class="secno">8.1 </bdi>Denial of Service</a></li><li class="tocline"><a class="tocxref" href="#security-consideration-amp-ddos"><bdi class="secno">8.2 </bdi>Amplification and Distributed Denial of Service</a></li><li class="tocline"><a class="tocxref" href="#security-consideration-lan-self-discovery"><bdi class="secno">8.3 </bdi>Self-Discovery on LANs</a></li></ol></li><li class="tocline"><a class="tocxref" href="#privacy-considerations"><bdi class="secno">9. </bdi>Privacy Considerations</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#privacy-consideration-location-tracking"><bdi class="secno">9.1 </bdi>Location Tracking and Profiling</a></li><li class="tocline"><a class="tocxref" href="#privacy-consideration-query-tracking"><bdi class="secno">9.2 </bdi>Query Tracking</a></li></ol></li><li class="tocline"><a class="tocxref" href="#performance-considerations"><bdi class="secno">10. </bdi>Performance Considerations</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#perf-incremental-transfer"><bdi class="secno">10.1 </bdi>Incremental Transfer</a></li></ol></li><li class="tocline"><a class="tocxref" href="#iana-considerations"><bdi class="secno">11. </bdi>IANA Considerations</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#well-known-uri-suffix"><bdi class="secno">11.1 </bdi>Well-Known URI Registration</a></li><li class="tocline"><a class="tocxref" href="#service-name"><bdi class="secno">11.2 </bdi>Service Name Registration</a></li><li class="tocline"><a class="tocxref" href="#core-resource-type"><bdi class="secno">11.3 </bdi>CoRE Resource Types Registration</a></li></ol></li><li class="tocline"><a class="tocxref" href="#other-name-considerations"><bdi class="secno">12. </bdi>Other Name Registration Considerations</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#did-service-name"><bdi class="secno">12.1 </bdi>DID Service Name Registration</a></li></ol></li><li class="tocline"><a class="tocxref" href="#tdd-extensions-jsonschema"><bdi class="secno">A. </bdi>JSON Schema for WoT Discovery TD-extensions</a></li><li class="tocline"><a class="tocxref" href="#changes"><bdi class="secno">B. </bdi>Recent Specification Changes</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#changes-from-cr"><bdi class="secno">B.1 </bdi>Changes from 19 January 2023 Candidate Recommendation</a></li><li class="tocline"><a class="tocxref" href="#changes-from-third-draft"><bdi class="secno">B.2 </bdi>Changes from 10 August 2022 Working Draft</a></li><li class="tocline"><a class="tocxref" href="#changes-from-second-draft"><bdi class="secno">B.3 </bdi>Changes from 2 June 2021 Working Draft</a></li><li class="tocline"><a class="tocxref" href="#changes-from-first-draft"><bdi class="secno">B.4 </bdi>Changes from 24 November 2020 First Public Working Draft</a></li></ol></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><bdi class="secno">C. </bdi>Acknowledgments</a></li><li class="tocline"><a class="tocxref" href="#references"><bdi class="secno">D. </bdi>References</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#normative-references"><bdi class="secno">D.1 </bdi>Normative references</a></li><li class="tocline"><a class="tocxref" href="#informative-references"><bdi class="secno">D.2 </bdi>Informative references</a></li></ol></li></ol></nav>
<section id="introduction"><div class="header-wrapper"><h2 id="x1-introduction"><bdi class="secno">1. </bdi>Introduction</h2><a class="self-link" href="#introduction" aria-label="Permalink for Section 1."></a></div>
<p>The Web of Things (WoT) defines an architecture that supports the integration
and use of web technologies with IoT devices.
The WoT Architecture [<cite><a class="bibref" data-link-type="biblio" href="#bib-wot-architecture11" title="Web of Things (WoT) Architecture 1.1">wot-architecture11</a></cite>] document defines the basic
concepts and patterns of usage supported.
However, the WoT Thing Description [<cite><a class="bibref" data-link-type="biblio" href="#bib-wot-thing-description11" title="Web of Things (WoT) Thing Description 1.1">wot-thing-description11</a></cite>] is a key
specification for WoT Discovery since it is the purpose of WoT Discovery
to make WoT Thing Descriptions available.
Specifically, WoT Discovery has to allow authenticated and authorized entities
(and only those entities) to find WoT Thing Descriptions satisfying a set of
criteria, such as
having certain semantics,
or containing certain interactions. Conversely, in order to support
security and privacy objectives, the WoT Discovery process must not
leak information to unauthorized entities. This includes leaking information
that a given entity is requesting certain information, not just the information
distributed in the Thing Descriptions themselves.
</p>
<p>There are already a number of discovery mechanisms defined [<cite><a class="bibref" data-link-type="biblio" href="#bib-discovery-categorization-iot" title="A Categorization of Discovery Technologies for the Internet of Things">Discovery-Categorization-IoT</a></cite>],
so we have to establish why we are proposing a new one. First, many existing
discovery mechanisms have relatively weak security and privacy protections.
One of our objectives is to establish a mechanism that not only uses best
practices to protect metadata, but that can be upgraded to support future
best practices as needed.
Second, we are using discovery in a broad sense to include both local and
non-local mechanisms. While a local mechanism might use a broadcast protocol,
non-local mechanisms might go beyond the current network segment where broadcast
is not scalable, and so a different approach, such as a search service, is needed.
Our approach is to use existing mechanisms as needed to bootstrap into a more
general and secure metadata distribution system.
Third, the metadata we are distributing, the WoT Thing Description, is highly
structured and includes rich data such as data schemas and semantic annotations.
Existing discovery mechanisms based on a list of simple key-value pairs are
not appropriate.
At the same time,
use of existing standards for semantic data query,
such as SPARQL [<cite><a class="bibref" data-link-type="biblio" href="#bib-sparql11-overview" title="SPARQL 1.1 Overview">SPARQL11-OVERVIEW</a></cite>],
while potentially suitable for some advanced use cases,
might require too much effort for many anticipated IoT applications.
Therefore in order to address more basic applications,
we also define some simpler query mechanisms.
</p>
<p>After defining some basic terminology, we will summarize the basic use cases and
requirements for WoT Discovery. These are a subset of the more detailed and
exhaustive use cases and requirements presented in the WoT Use Cases [<cite><a class="bibref" data-link-type="biblio" href="#bib-wot-usecases" title="Web of Things (WoT): Use Cases">wot-usecases</a></cite>] and
WoT Architecture [<cite><a class="bibref" data-link-type="biblio" href="#bib-wot-architecture11" title="Web of Things (WoT) Architecture 1.1">wot-architecture11</a></cite>] documents.
Then we will describe the basic architecture of the WoT Discovery process,
which uses a two-phase Introduction/Exploration approach. The basic goal of this
architecture is to be able to use existing discovery standards to bootstrap
access to protected discovery services, but to distribute detailed metadata only to
authorized users, and to also protect those making queries from eavesdroppers
as much as possible.
We then describe details of specific Introduction and Exploration mechanisms.
In particular, we define in detail a normative API for a
WoT Thing Description Directory (WoT TDD) service that provides a search mechanism for
collections of WoT Thing Descriptions that can be dynamically registered by Things or
entities acting on their behalf. The WoT Discovery mechanism however also supports
distribution of single TDs from regular web services, with a special case of this
being self-description.
Finally, we discuss some security and privacy considerations, including a set of
potential risks and mitigations.
</p>
</section>
<section id="conformance"><div class="header-wrapper"><h2 id="x2-conformance"><bdi class="secno">2. </bdi>Conformance</h2><a class="self-link" href="#conformance" aria-label="Permalink for Section 2."></a></div><p>As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.</p><p>
The key words <em class="rfc2119">MAY</em>, <em class="rfc2119">MUST</em>, <em class="rfc2119">OPTIONAL</em>, <em class="rfc2119">RECOMMENDED</em>, <em class="rfc2119">SHOULD</em>, and <em class="rfc2119">SHOULD NOT</em> in this document
are to be interpreted as described in
<a href="https://datatracker.ietf.org/doc/html/bcp14">BCP 14</a>
[<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc2119" title="Key words for use in RFCs to Indicate Requirement Levels">RFC2119</a></cite>] [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc8174" title="Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words">RFC8174</a></cite>]
when, and only when, they appear in all capitals, as shown here.
</p></section>
<section id="terminology" class="informative"><div class="header-wrapper"><h2 id="x3-terminology"><bdi class="secno">3. </bdi>Terminology</h2><a class="self-link" href="#terminology" aria-label="Permalink for Section 3."></a></div><p><em>This section is non-normative.</em></p>
<p>
The fundamental WoT terminology such as
<dfn id="dfn-thing" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Thing</dfn>,
<dfn data-plurals="thing descriptions" id="dfn-thing-description" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Thing Description</dfn> (<dfn data-plurals="tds" id="dfn-td" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">TD</dfn>),
<dfn id="dfn-thing-model" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Thing Model</dfn> (<dfn id="dfn-tm" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">TM</dfn>),
<dfn id="dfn-property" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Property</dfn>,
<dfn id="dfn-action" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Action</dfn>,
<dfn id="dfn-event" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Event</dfn>,
<dfn data-lt="WoT Anonymous Thing Description|Anonymous TD" data-plurals="anonymous tds" id="dfn-wot-anonymous-thing-description" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Anonymous TD</dfn>,
<dfn data-lt="WoT Discoverer|Discoverer" id="dfn-wot-discoverer" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Discoverer</dfn>,
<dfn data-lt="WoT Discovery|Discovery" id="dfn-wot-discovery" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Discovery</dfn>,
<dfn data-lt="WoT Exploration|Exploration" id="dfn-wot-exploration" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Exploration</dfn>,
<dfn data-lt="WoT Introduction|Introduction" id="dfn-wot-introduction" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Introduction</dfn>,
<dfn data-lt="WoT Thing Description Server|Thing Description Server" id="dfn-wot-thing-description-server" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Thing Description Server</dfn>
(<dfn data-lt="WoT TD Server|TD Server" data-plurals="td servers" id="dfn-wot-td-server" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">TD Server</dfn>),
<dfn data-lt="WoT Thing Description Directory|Thing Description Directory" data-plurals="thing description directories" id="dfn-wot-thing-description-directory" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Thing Description Directory</dfn>
(<dfn data-lt="WoT TDD|TDD" id="dfn-wot-tdd" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">TDD</dfn>),
<dfn data-lt="WoT Partial Thing Description|Partial TD" id="dfn-wot-partial-thing-description" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Partial TD</dfn>,
<dfn data-lt="WoT Enriched Thing Description|Enriched TD" data-plurals="enriched tds" id="dfn-wot-enriched-thing-description" tabindex="0" aria-haspopup="dialog" data-dfn-type="dfn">Enriched TD</dfn>
are defined in <a href="https://www.w3.org/TR/wot-architecture11/#terminology">Section 3</a>
of the WoT Architecture 1.1 specification [<cite><a class="bibref" data-link-type="biblio" href="#bib-wot-architecture11" title="Web of Things (WoT) Architecture 1.1">wot-architecture11</a></cite>].
</p>
</section>
<section id="architecture" class="informative"><div class="header-wrapper"><h2 id="x4-architecture"><bdi class="secno">4. </bdi>Architecture</h2><a class="self-link" href="#architecture" aria-label="Permalink for Section 4."></a></div><p><em>This section is non-normative.</em></p>
<p>
<a href="#discovery-overview" class="fig-ref" title="Discovery architecture overview. A set of open Introduction mechanisms provides a set of URLs, which point at Exploration services that only provide metadata (TDs) after suitable authentication. Thing Links and Thing Description Directories provide additional flexibility but retrieving further results from these is at the discretion of the application.">Figure <bdi class="">1</bdi></a> shows an overview of the WoT Discovery process.
Discovery uses a two-phase architecture to resolve the competing requirements to be
both open and to restrict access to metadata to authorized entities.
In the first phase, one or more of a set of relatively open
"Introduction" mechanisms may be used to generate a set of candidate URLs.
These URLs do not themselves contain metadata,
but are used in the second stage to reference "Exploration"
services that can actually provide metadata, after authentication,
in the form of <a href="#dfn-thing-description" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-thing-description-1">Thing Descriptions</a>.
</p>
<figure id="discovery-overview">
<img src="images/overview.png" srcset="images/overview.svg" class="wot-diagram" alt="Discovery process overview">
<figcaption><a class="self-link" href="#discovery-overview">Figure <bdi class="figno">1</bdi></a> <span class="fig-title">Discovery architecture overview.
A set of open Introduction mechanisms provides a set of URLs, which
point at Exploration services that only provide metadata (TDs) after suitable
authentication. Thing Links and Thing Description Directories provide
additional flexibility but retrieving further results from these is
at the discretion of the application.
</span></figcaption>
</figure>
<p>
The intention is that Introduction mechanisms are relatively open "first contact"
mechanisms to provide a starting point for the rest of the Discovery process.
In this document we specify details on several Introduction
mechanisms, suitable for different use cases, including both local and non-local
scenarios, but Introductions can in fact be provided by any mechanism that can return a URL.
Introductions, however, do not include any security or privacy controls and
so should not provide metadata directly.
Instead, the URLs provided by Introduction mechanisms reference
"Exploration" services. Exploration services actually do provide metadata,
but only after suitable authentication and access controls have been applied.
</p>
<p>
The Discovery process can produce a <em>set</em> of URLs as output from
its Introduction phase, even if only one Introduction mechanism is used
(some Introduction mechanisms can themselves return multiple URLs).
The final output after the Exploration phase
can also be a <em>set</em> of Thing Descriptions.
</p>
<p>
Each URL provided by the Introduction phase always points at an
Exploration service endpoint that will return a single Thing Description.
In the simplest case this URL references an ordinary resource
provided by a web server which provides the Thing Description of a Thing
describing an IoT endpoint device.
As a special case of this, for self-describing Things an Introduction URL might
point directly at an endpoint provided by a
Thing serving its own Thing Description.
</p>
<p>
In general Thing Descriptions might be provided in various ways and
in particular may not be self-describing.
For example,
</p>
<ul>
<li>brownfield devices not designed with the WoT
specification in mind will not be capable of serving their
own Thing Descriptions;
</li>
<li>battery-powered devices may not be online
most of the time; and
</li>
<li>some devices may not be powerful enough to manage and
serve TDs directly.
</li>
</ul>
<p>
The Thing Description for such Things should be provided
by separate services.
</p>
<p>
This document specifies two special cases that allow for more flexibility:
</p>
<ul>
<li>A Thing Description referenced by an Introduction URL
may describe a <a href="#exploration-td-type-thingdirectory">Thing Description Directory</a> service.
A Thing Description Directory service (which is still a Thing)
maintains a (possibly dynamic) database of Thing Descriptions.
Thing Description Directories that maintain large numbers of
Thing Descriptions may also support queries that can be used to
selectively retrieve Thing Descriptions.
</li>
<li>
The second special case is a
<a href="#exploration-td-type-thinglink">Thing Link</a>.
A Thing Link is also a Thing Description,
but rather than describing a Thing directly, it holds a link to
a Thing Description hosted elsewhere.
A Thing Description Directory can also store Thing Links
which can redirect to other Thing Description Directories,
allowing for a linked directory structure.
</li>
</ul>
<p>
It is <em>not</em> mandatory for the Discovery process to retrieve
the contents of Thing Description Directories and return them as
part of the results,
because in general this might result in a huge set of results.
Instead the application
should scan the results for Thing Description Directory TDs and
decide whether to retrieve TDs from them, possibly selectively.
Likewise, it is not required to follow Thing Links automatically;
instead the application may choose to follow them selectively.
</p>
</section>
<section id="discoverer-process" class="normative"><div class="header-wrapper"><h2 id="x5-discoverer-process"><bdi class="secno">5. </bdi>Discoverer Process</h2><a class="self-link" href="#discoverer-process" aria-label="Permalink for Section 5."></a></div>
<p>In this section we will describe the WoT Discovery process from the point of view of a client,
and what it means to say that a client supports WoT Discovery.
We will use the term <a href="#dfn-wot-discoverer" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-discoverer-1">Discoverer</a> for an entity that is a client of the WoT Discovery
process.
A Discoverer may or may not be a full Consumer.
A Discoverer does however need to read and extract information from special TDs for Directories
and Thing Links and use specific affordances and links provided in them.
Conversely, a Consumer may not support Discovery, although it is recommended
[<cite><a class="bibref" data-link-type="biblio" href="#bib-wot-architecture11" title="Web of Things (WoT) Architecture 1.1">wot-architecture11</a></cite>].
</p>
<p>
The WoT Discovery process is designed so that nearly any client that can fetch a single TD
given a single URI can be said to support WoT Discovery.
Of course, Discoverers may support more powerful Discovery mechanisms, but some of these
have additional requirements.
Some Introduction mechanisms can return multiple URLs,
each of which can in turn be used to fetch at least one TD.
So even without a TDD, it is possible to discover multiple TDs.
</p>
<p>
The following assertions describe the specific responsibilities of a Discoverer:
</p>
<ul>
<li><span class="rfc2119-assertion" id="discoverer-must-support-intros">
A Discoverer <em class="rfc2119">MUST</em> support at least one Introduction mechanism.</span>
The simplest Introduction mechanism, Direct, simply provides a single URL of a target TD.
This assertion results in different minimal requirements depending on
which Introduction mechanism is selected out of the several available.
For example, when Direct is used as the sole Introduction mechanism,
at a minimum a Discoverer must be able to accept a single URL pointing at a TD.
Note, however, that this TD could still be describing a Directory.
Another option would be for a Discoverer to implement, as its sole
Introduction mechanism, an "automatic" Introduction mechanism such as
DNS-SD, possibly in combination with mDNS.
In this case the application
code running in the Discoverer
would not have to supply any additional information to invoke Discovery.
</li>
<li><span class="rfc2119-assertion" id="discoverer-must-support-fetching">
A Discoverer <em class="rfc2119">MUST</em> support fetching a TD from at least one URL provided as part of the Introduction process.</span>
In other words, not only must a Discoverer accept URLs pointing at TDs, it must be
able to fetch that TD, for example by using a GET for an HTTP URL.
It is permissible to split the implementation of a Discoverer into two components, one that
fetches/reads a TD and sets up a configuration during installation to be used by a
run-time component that cannot itself read TDs.
In this case, however, the latter component is not by itself a Discoverer.
</li>
<li><span class="rfc2119-assertion" id="discoverer-may-multiple-intro">
A Discoverer <em class="rfc2119">MAY</em> support multiple invocations of the same Introduction mechanism.</span>
If multiple invocations of a single Introduction mechanism is supported,
or if multiple Introduction mechanisms are used, then the Discoverer needs to
manage a set of Introduction results.
Some Introduction mechanisms themselves return a set of results, e.g. CoRE-RD, DID, or DNS-SD.
Some mechanisms, such as scanning Bluetooth beacons, may intrinsically result in separate multiple "invocations".
However, this Discoverer requirement is optional to support an important special case:
it is permissible to have a simple
Discoverer that only supports a single invocation of a Direct Introduction,
directly specifying a single TD via a URL.
</li>
<li><span class="rfc2119-assertion" id="discoverer-merge-intros">
A Discoverer <em class="rfc2119">MUST</em> be able to merge URLs resulting from
multiple Introduction mechanisms, multiple results from a single Introduction mechanism,
and multiple Introduction invocations into a single set.</span>
Note that even if only one Introduction mechanism is supported multiple results might be
produced.
This assertion states that the overall output of the Introduction phase is
a single set of URLs.
The word "set" is used here in the mathematical sense: the results are unordered and unique.
Uniqueness means that if multiple Introductions have the same result, they are merged into
a single result.
If the Discoverer only supports one Introduction mechanism and that mechanism
can only produce one URL, then the "merge" is trivial.
</li>
<li><span class="rfc2119-assertion" id="discoverer-td-identify">
A Discoverer <em class="rfc2119">MUST</em> be able to identify whether a TD fetched from an
Introduction URL has <a href="#exploration-td-type-thingdirectory">Thing Directory</a>
or <a href="#exploration-td-type-thingdirectory">Thing Link</a> type.</span>
This implies that the Discoverer needs to be able
to check the <code>@type</code> field and make this distinction.
A Discoverer can decide whether or not to follow links or fetch TDD contents.
There are some use cases where a Consumer may not expand certain URLs, for example links pointing
at external resources, or when a TDD contains many TDs and fetching them all
would exceed the Consumer's memory processing capabilities.
</li>
<li><span class="rfc2119-assertion" id="discoverer-fetch-tdd">
A Discoverer <em class="rfc2119">MAY</em> fetch additional TDs from any Exploration mechanism
described in its initial set of TDs (including, in particular, Thing Description Directories)
and add them into the set of TD results.</span>
This only adds the results of fetching TDs from an Exploration mechanism to the set of
results. These new results do not delete the original TD describing the Exploration mechanism.
A Discoverer implementation can decide whether or not to fetch TDD contents.
Implementers should consider the fact that TDDs may be large and fetching the contents of an entire TDD
might be prohibitively expensive.
</li>
<li><span class="rfc2119-assertion" id="discoverer-fetch-links">
A Discoverer <em class="rfc2119">MAY</em> fetch source TDs from the targets of the links in a <a href="#exploration-td-type-thingdirectory">Thing Link</a>
described in its initial set of TDs and add them into the set of TD results.</span>
This only adds the results of fetching TDs from a Thing Link to the set of
results. These new results do not delete the original TD describing the Thing Link.
A Discoverer implementation can decide whether or not to fetch the targets of Thing Links.
</li>
<li><span class="rfc2119-assertion" id="discoverer-fetch-iteration">
A Discoverer <em class="rfc2119">MAY</em> fetch additional TDs iteratively from any <a href="#exploration-td-type-thingdirectory">Thing Link</a> or
Exploration mechanism described in its set of TDs and add them into the set of TD results.</span>
This only adds the results of fetching TDs from an Exploration mechanism to the set of
results. These new results do not delete the original TD describing the Exploration mechanism.
</li>
<li><span class="rfc2119-assertion" id="discoverer-termination">
A Discoverer <em class="rfc2119">MAY</em> terminate fetching additional TDs at any point or for
any reason.</span>
</li>
<li><span class="rfc2119-assertion" id="discoverer-any-order">
A Discoverer <em class="rfc2119">MAY</em> fetch additional TDs by following links or fetching
additional TDs from Exploration mechanisms (e.g. TDDs) in any order.</span>
The Discoverer can fetch additional TDs in any order from any Exploration mechanism and is not
required to use all of them.
</li>
<li><span class="rfc2119-assertion" id="discoverer-track">
A Discoverer <em class="rfc2119">MUST</em> track which TDs describing links or Exploration mechanisms
have already been fetched and avoid fetching duplicate results.</span>
This is to avoid infinite loops. Note that Thing Description Directories can easily refer to each other,
for example, so fetching the TDs from a TDD, then fetching all those TDs will give another copy of the
original TDD's TD. This second copy should NOT trigger further fetches.
Note that tracking cannot depend only on the value of "id" fields in TDs since this
field is optional.
</li>
</ul>
<p>
The above process supports a way to let Directories reference other Directories without duplicating their TDs:
a Directory wanting to reference other Directories should include a <a href="#exploration-td-type-thingdirectory">Thing Link</a> with a "describedby" relation to the
TD of the other Directory service. Then the above process would expand the Thing Link to obtain the actual TD of the Directory,
and then (optionally) use the appropriate Directory affordance to access the contents of the linked Directory.
Note that such a Thing Link points at the TD of the Directory, not at the Directory itself. These
may or may not be hosted in the same location.
</p><p>
Recursively fetching the contents of such linked directories, especially without a specific
query or filter, could easily result in downloading a large amount of data. Such recursive expansion should be limited to use
cases that require it, such as inventory, auditing, or indexing.
</p><p>
URLs for Directory services can also be
used with the federation capabilities of SPARQL queries, noted below, which in most cases will be a more efficient way
to collect specific information from a set of distributed directory services.
However, SPARQL requires the URL of a SPARQL endpoint for such federation, which can be found in the TDs
of Directories supporting SPARQL queries. This is not the same as the URL pointing at the TD of a Directory.
</p>
<p></p>
</section>
<section id="introduction-mech" class="normative"><div class="header-wrapper"><h2 id="x6-introduction-mechanisms"><bdi class="secno">6. </bdi>Introduction Mechanisms</h2><a class="self-link" href="#introduction-mech" aria-label="Permalink for Section 6."></a></div>
<p>This chapter describes mechanisms for initial contact with
Things or <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-1">Thing Description Directories</a>.
Any of the following mechanisms may
be provided by the Thing or the <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-2">Thing Description Directory</a> to Consumers.
The result of an introduction mechanism is always a URL (address) of an exploration service
which can be used to obtain detailed metadata (TDs) after suitable authentication.
It is also possible for multiple introduction mechanisms to be used and the results merged.
No particular introduction mechanism is mandatory, as long as the URL of at least one
exploration service is somehow obtained.
</p>
<section id="introduction-direct" class="normative"><div class="header-wrapper"><h3 id="x6-1-direct"><bdi class="secno">6.1 </bdi>Direct</h3><a class="self-link" href="#introduction-direct" aria-label="Permalink for Section 6.1"></a></div>
<p><span class="rfc2119-assertion" id="introduction-direct-url">To obtain an URL of an exploration service, any mechanism that results in a single URL <em class="rfc2119">MAY</em> be used.</span>
This includes Bluetooth beacons, QR codes, and written URLs to be
typed by a user.
<span class="rfc2119-assertion" id="introduction-direct-thing-description">
A request on all such URLs <em class="rfc2119">MUST</em> result in a TD as prescribed in
<a href="#exploration-mech" data-matched-text="[[[#exploration-mech]]]" class="sec-ref"><bdi class="secno">7. </bdi>Exploration Mechanisms</a>.</span>
For self-describing Things, this can be the TD of the Thing itself.
<span class="rfc2119-assertion" id="introduction-direct-directory-description">
If the URL references a <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-3">Thing Description Directory</a>, this <em class="rfc2119">MUST</em> be the Thing Description of the
<a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-4">Thing Description Directory</a>.</span>
</p>
</section>
<section id="introduction-well-known" class="normative"><div class="header-wrapper"><h3 id="x6-2-well-known-uris"><bdi class="secno">6.2 </bdi>Well-Known URIs</h3><a class="self-link" href="#introduction-well-known" aria-label="Permalink for Section 6.2"></a></div>
<p>
<span class="rfc2119-assertion" id="introduction-well-known-uri">A Thing or <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-5">Thing Description Directory</a> <em class="rfc2119">MAY</em> use the Well-Known Uniform Resource Identifier [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc8615" title="Well-Known Uniform Resource Identifiers (URIs)">RFC8615</a></cite>]
to advertise its presence.</span>
<span class="rfc2119-assertion" id="introduction-well-known-path">If a Thing or <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-6">Thing Description Directory</a> use the Well-Known Uniform Resource Identifier [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc8615" title="Well-Known Uniform Resource Identifiers (URIs)">RFC8615</a></cite>] to advertise its presence, it <em class="rfc2119">MUST</em> register its own Thing Description
into the following path:
<code>/.well-known/wot</code>.</span>
</p><p>
<span class="rfc2119-assertion" id="introduction-well-known-thing-description">
When a request is made at the above Well-Known URI, the server <em class="rfc2119">MUST</em> return
a Thing Description as prescribed in <a href="#exploration-mech" data-matched-text="[[[#exploration-mech]]]" class="sec-ref"><bdi class="secno">7. </bdi>Exploration Mechanisms</a>.</span>
</p>
</section>
<section id="introduction-dns-sd-sec" class="normative"><div class="header-wrapper"><h3 id="x6-3-dns-based-service-discovery"><bdi class="secno">6.3 </bdi>DNS-Based Service Discovery</h3><a class="self-link" href="#introduction-dns-sd-sec" aria-label="Permalink for Section 6.3"></a></div>
<p><span class="rfc2119-assertion" id="introduction-dns-sd">A Thing or <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-7">Thing Description Directory</a> <em class="rfc2119">MAY</em> use DNS-Based Service Discovery (DNS-SD)[<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc6763" title="DNS-Based Service Discovery">RFC6763</a></cite>].</span>
This can be also be used on the same local network in combination with Multicast DNS (mDNS)[<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc6762" title="Multicast DNS">RFC6762</a></cite>].
</p>
<p>
The following table lists the service names and protocols for advertising their presense.
These are normative since each has a valid use with existing exploration mechanisms:
</p><table class="def">
<thead>
<tr>
<th>Service name</th>
<th>Thing or TDD</th>
<th>Protocol</th>
</tr>
</thead>
<tbody>
<tr class="rfc2119-table-assertion" id="introduction-dns-sd-service-name">
<td><code>_wot._tcp</code></td>
<td>Thing</td>
<td>HTTP over TCP, HTTP over TLS/TCP, CoAP over TCP, or CoAP over TLS/TCP</td>
</tr>
<tr class="rfc2119-table-assertion" id="introduction-dns-sd-service-name-directory">
<td><code>_directory._sub._wot._tcp</code></td>
<td>TDD</td>
<td>HTTP over TCP, HTTP over TLS/TCP, CoAP over TCP, or CoAP over TLS/TCP</td>
</tr>
<tr class="rfc2119-table-assertion" id="introduction-dns-sd-service-name-udp">
<td><code>_wot._udp</code></td>
<td>Thing</td>
<td>CoAP over UDP or CoAP over DTLS/UDP</td>
</tr>
</tbody></table>
<p></p>
<p>The following additional service name has been defined for future use.
This definition is however informative
since there is currently no defined directory service using CoAP over UDP:
</p><table class="def">
<thead>
<tr>
<th>Service name</th>
<th>Thing or TDD</th>
<th>Protocol</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>_directory._sub._wot._udp</code></td>
<td>TDD</td>
<td>CoAP over UDP or CoAP over DTLS/UDP</td>
</tr>
</tbody>
</table>
<p></p>
<div class="rfc2119-assertion" id="introduction-dns-sd-txt-record">
<p>
For TCP-based services,
the following information <em class="rfc2119">MUST</em> be included in the <code>TXT</code>
record that is pointed to by the Service Instance Name:
</p>
<dl>
<dt><code>td</code></dt>
<dd>Absolute pathname of the Thing Description of the Thing or Thing Description of the <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-8">Thing Description Directory</a>.</dd>
<dt><code>type</code></dt>
<dd>Type of the Thing Description, i.e. <code>Thing</code> or <code>Directory</code>.
If omitted, the type is assumed to be <code>Thing</code>.</dd>
<dt><code>scheme</code></dt>
<dd>Scheme part of URL. One of the following values can be specified, with the standard registered URI interpretations [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc7595" title="Guidelines and Registration Procedures for URI Schemes">RFC7595</a></cite>]: <code>http</code> (HTTP over TCP), <code>https</code> (HTTP over TLS/TCP), <code>coap+tcp</code> (CoAP over TCP), or <code>coaps+tcp</code> (CoAP over TLS/TCP).
If omitted, the scheme is assumed to be <code>http</code>.</dd>
</dl>
</div>
<div class="rfc2119-assertion" id="introduction-dns-sd-txt-record-udp">
<p>
For UDP-based services,
the following information <em class="rfc2119">MUST</em> be included in the <code>TXT</code>
record that is pointed to by the Service Instance Name:
</p>
<dl>
<dt><code>td</code></dt>
<dd>Absolute pathname of the Thing Description of the Thing or Thing Description of the <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-9">Thing Description Directory</a>.</dd>
<dt><code>type</code></dt>
<dd>Type of the Thing Description, i.e. <code>Thing</code> or <code>Directory</code>.
If omitted, the type is assumed to be <code>Thing</code>.</dd>
<dt><code>scheme</code></dt>
<dd>Scheme part of URL. One of the following values can be specified, with the standard registered URI interpretations [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc7595" title="Guidelines and Registration Procedures for URI Schemes">RFC7595</a></cite>]: <code>coap</code> (CoAP over UDP) or <code>coaps</code> (CoAP over DTLS/UDP).
If omitted, the scheme is assumed to be <code>coap</code>.</dd>
</dl>
</div>
<p>
<a href="#sequence-dnssd-thing" class="fig-ref" title="Using mDNS for discovery of the Thing Description of a Thing">Figure <bdi class="">2</bdi></a> and <a href="#sequence-dnssd-directory" class="fig-ref" title="Using mDNS for discovery of the Thing Description of a Thing Description Directory (TDD)">Figure <bdi class="">3</bdi></a> shows example sequences
supporting discovery of a Thing or a <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-10">Thing Description Directory</a> using DNS-SD and mDNS.
</p>
<figure id="sequence-dnssd-thing">
<img src="images/sequence-dnssd-thing.png" srcset="images/sequence-dnssd-thing.svg" class="wot-diagram" alt="An example sequence of discovery of Thing using DNS-SD and mDNS">
<figcaption><a class="self-link" href="#sequence-dnssd-thing">Figure <bdi class="figno">2</bdi></a> <span class="fig-title">Using mDNS for discovery of the Thing Description of a Thing</span></figcaption>
</figure>
<figure id="sequence-dnssd-directory">
<img src="images/sequence-dnssd-directory.png" srcset="images/sequence-dnssd-directory.svg" class="wot-diagram" alt="An example sequence of discovery of directory service using DNS-SD and mDNS">
<figcaption><a class="self-link" href="#sequence-dnssd-directory">Figure <bdi class="figno">3</bdi></a> <span class="fig-title">Using mDNS for discovery of the Thing Description of a Thing Description Directory (TDD)</span></figcaption>
</figure>
</section>
<section id="introduction-core-rd-sec" class="normative"><div class="header-wrapper"><h3 id="x6-4-core-link-format-and-core-resource-directory"><bdi class="secno">6.4 </bdi>CoRE Link Format and CoRE Resource Directory</h3><a class="self-link" href="#introduction-core-rd-sec" aria-label="Permalink for Section 6.4"></a></div>
<p>
<span class="rfc2119-assertion" id="introduction-core-rd">A Thing or <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-11">Thing Description Directory</a> <em class="rfc2119">MAY</em> advertise its presence using the
Constrained RESTful Environment (CoRE) Link Format [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc6690" title="Constrained RESTful Environments (CoRE) Link Format">RFC6690</a></cite>].</span>
<span class="rfc2119-assertion" id="introduction-core-rd-directory">
A <a href="#dfn-thing" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-thing-1">Thing</a> or <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-12">Thing Description Directory</a> <em class="rfc2119">MAY</em> use the CoRE Resource Directory [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc9176" title="Constrained RESTful Environments (CoRE) Resource Directory">RFC9176</a></cite>]
to register a link to its corresponding Thing Description.</span>
</p>
<p>
<span class="rfc2119-assertion" id="introduction-core-rd-resource-type-thing">
The resource type (<code>rt</code>) of the Link that targets the Thing Description of the Thing
<em class="rfc2119">MUST</em> be <code>wot.thing</code>.</span>
<span class="rfc2119-assertion" id="introduction-core-rd-resource-type-directory">
The resource type of the Link that targets the Thing Description of the <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-13">Thing Description Directory</a>
<em class="rfc2119">MUST</em> be <code>wot.directory</code>.</span>
</p>
</section>
<section id="introduction-did-sec" class="normative"><div class="header-wrapper"><h3 id="x6-5-did-documents"><bdi class="secno">6.5 </bdi>DID Documents</h3><a class="self-link" href="#introduction-did-sec" aria-label="Permalink for Section 6.5"></a></div>
<p><span class="rfc2119-assertion" id="introduction-did">A <a href="#dfn-thing" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-thing-2">Thing</a> or <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-14">Thing Description Directory</a>
using a Decentralized Identifier (DID) [<cite><a class="bibref" data-link-type="biblio" href="#bib-did-core" title="Decentralized Identifiers (DIDs) v1.0">DID-CORE</a></cite>] <em class="rfc2119">MAY</em> advertise the location of its <a href="#dfn-td" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-td-1">TD</a>
by including a DID Service Endpoint of type
<code>WotThing</code> or <code>WotDirectory</code>, respectively, in the DID Document that
the TD's identifier resolves to.</span>
</p>
<p><span class="rfc2119-assertion" id="introduction-did-service-context">In order to define Service Endpoints
for WoT Discovery, the DID Document obtained by resolving the DID of a <a href="#dfn-thing" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-thing-3">Thing</a> or <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-15">Thing Description Directory</a>
<em class="rfc2119">MUST</em> include the URL <code>https://www.w3.org/2022/wot/discovery-did</code> in its <code>@context</code>
[<cite><a class="bibref" data-link-type="biblio" href="#bib-did-spec-registries" title="DID Specification Registries">did-spec-registries</a></cite>].
</span>
</p>
<p><span class="rfc2119-assertion" id="introduction-did-service-endpoint">
If the DID Document obtained by resolving the DID of a <a href="#dfn-thing" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-thing-4">Thing</a> or <a href="#dfn-wot-thing-description-directory" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-wot-thing-description-directory-16">Thing Description Directory</a>
contains a Service Endpoint of type <code>WotThing</code> or <code>WotDirectory</code>, respectively,
then this Service Endpoint <em class="rfc2119">MUST</em> refer to the <a href="#dfn-td" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-td-2">TD</a> describing that Thing