specification/protocol.html at main · solid/specification · GitHub

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" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta charset="utf-8" />
    <title>Solid Protocol</title>
    <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport" />
<style>
main,
main>article,
main>article>div {
background:inherit;
}
body {
counter-reset:section sub-section appendix sub-appendix;
}
code, samp { color: #e00; }
pre code, pre samp { color: var(--text); }
dfn { font-weight:inherit; }
.do.fragment a { border-bottom:0; }
.do.fragment a:hover { background:none; border-bottom:0; }
section figure pre { margin:1em 0; display:block; }
cite .bibref { font-style: normal; }
.tabs nav ul li { margin:0; }
div.issue, div.note, div.warning {
clear: both;
margin: 1em 0;
position: relative;
}
div.issue h3, div.note h3,
div.issue h4, div.note h4,
div.issue h5, div.note h5 {
margin:0;
font-weight:normal;
font-style:normal;
font-size:1em;
}
div.issue h3 > span, div.note h3 > span,
div.issue h4 > span, div.note h4 > span,
div.issue h5 > span, div.note h5 > span,
figure.example > figcaption > span {
text-transform: uppercase;
}
div.issue h3, div.issue h4, div.issue h5 {
color:var(--issueheading-text);
}
div.note h3, div.note h4, div.note h5 {
color:var(--noteheading-text);
}
figure.example figcaption {
color:var(--exampleheading-text);
}
main figure {
text-align:left;
}
figure[id] {
position:relative;
padding:0.5em;
}
figure[id] figcaption {
font-style:normal;
font-size:1em;
}
figure.example figcaption span + span {
text-transform:initial;
}
.copyright + hr {
border-style: solid;
}
header address a[href] {
float: right;
margin: 1rem 0 0.2rem 0.4rem;
background: transparent none repeat scroll 0 0;
border: medium none;
text-decoration: none;
}
header address img[src*="logos/W3C"] {
background: #1a5e9a none repeat scroll 0 0;
border-color: #1a5e9a;
border-image: none;
border-radius: 0.4rem;
border-style: solid;
border-width: 0.65rem 0.7rem 0.6rem;
color: white;
display: block;
font-weight: bold;
}
main article > h1 {
font-size: 220%;
font-weight:bold;
}
#acknowledgements ul { padding: 0; margin:0; }
#acknowledgements li { display:inline; }
#acknowledgements li:after { content: ", "; }
#acknowledgements li:last-child:after { content: ""; }
dd .contributed {
user-select: none;
}
aside.do { overflow:inherit; }
aside.do blockquote {
padding: 0; border: 0; margin: 0;
}
dl[id^="document-"] ul {
padding-left:0;
list-style-type:none;
}
dl [rel~="odrl:action"],
dl [rel~="odrl:action"] li {
display: inline;
}
dl [rel~="odrl:action"] li:after {
content: ", ";
}
dl [rel~="odrl:action"] li:last-child:after {
content: "";
}
aside section > .toc,
aside section > .toc ol {
margin-left: revert;
}
aside section > .toc li li {
margin-left: 1em;
font-size: revert;
}
table {
border-collapse:collapse;
}
table + table {
margin-top:2em;
}
caption {
text-align:left;
padding:0 0.25em 0.25em;
margin-bottom: 1em;
font-size: 1em;
font-style: revert;
font-weight: bold;
border-bottom: 1px solid;
}
caption, tbody, tfoot {
border-bottom:2pt solid #ccc;
}
thead,
thead th[colspan] {
border-bottom:1pt solid #ccc;
}
[rowspan] { vertical-align: bottom; }
tbody [rowspan] { vertical-align: middle; }
tbody th[scope="rowgroup"] {
border-bottom:3pt double #ccc;
}
tr {
border-bottom:1pt solid #ccc;
}
th, td {
padding:0.25em;
font-size:0.923em;
word-wrap:normal;
}
table ul,
table ol,
table li,
table p,
table dd {
margin:0;
text-align:left;
}
table ul,
table ol {
padding-left:1em;
}
tfoot td > * + * {
margin-top:1em;
}
tfoot dd:after { content: "\A"; white-space:pre; }
tfoot dt, tfoot dd { display:inline; }
tfoot dd { margin-left: 0.5em; }
tfoot dd + dt { margin-top:0; }
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]):not([id=exit-criteria]) {
counter-increment:section;
counter-reset:sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]) section:not([id$=references]):not([id=exit-criteria]) {
counter-increment:sub-section;
counter-reset:sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]) section:not([id$=references]):not([id=exit-criteria]) section {
counter-increment:sub-sub-section;
counter-reset:sub-sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]) section:not([id$=references]):not([id=exit-criteria]) section section {
counter-increment:sub-sub-sub-section;
counter-reset:sub-sub-sub-sub-section;
}
article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]):not([id=exit-criteria]):not([id^=table-of-]):not([id^=list-of-]) > h2:before {
content:counter(section) ".\00a0";
}
section:not([id$=references]):not([id^=changelog]):not([id=exit-criteria]):not([id^=table-of-]):not([id^=list-of-]) > h3:before {
content:counter(section) "." counter(sub-section) "\00a0";
}
section > h4:before {
content:counter(section)"." counter(sub-section) "." counter(sub-sub-section) "\00a0";
}
article section.appendix {
counter-increment:appendix;
counter-reset:sub-appendix;
}
article section[class~=appendix]:not([id=abstract]):not([id=sotd]):not([id=appendix]):not([id=acknowledgements]):not([id=changelog]):not([id=exit-criteria]) section {
counter-increment:sub-appendix;
counter-reset:sub-sub-appendix;
}
section.appendix > h2:before {
content:counter(appendix, upper-alpha) ".\00a0";
}
section.appendix section > h3:before {
content:counter(appendix, upper-alpha) "." counter(sub-appendix) "\00a0";
}
.self-link {
display: inline-block;
margin-right:0.25em;
user-select: none;
font-family: monospace;
font-style:normal;
font-weight:bold;
outline:none;
text-align:left;
text-decoration:underline;
border:0;
background-color:transparent;
line-height: 1;
vertical-align: initial;
}
figure[id] figcaption {
margin-left:1em;
}
figure[id] .self-link {
position:absolute;
top:1em;
left:0.5em;
}
.self-link:after {
content:"#";
font-size: initial;
}
aside > .self-link:after {
content:"|";
}
dl > .self-link:after {
content:"☝";
}
nav > .self-link:after {
content:"☛";
}
p > .self-link:after {
content:"¶";
}
section > .self-link:after {
content:"§";
}
figure > .self-link:after {
content:"❦";
}
table > .self-link:after {
content:"𝄜";
}
[rel~="spec:requirement"] .self-link:after {
content:"◎";
}
[rel~="spec:advisement"] .self-link:after {
content:"✪";
}
h2,h3,h4,h5,h6 {
display:inline-block;
margin-block:0;
margin-bottom:0.5rem;
}
</style>
    <link href="https://www.w3.org/StyleSheets/TR/2021/cg-draft" media="all" rel="stylesheet" title="CG-DRAFT" />
    <link href="https://www.w3.org/StyleSheets/TR/2021/dark.css" media="(prefers-color-scheme: dark)" rel="stylesheet" />
  </head>

  <body about="" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# owl: http://www.w3.org/2002/07/owl# xsd: http://www.w3.org/2001/XMLSchema# dcterms: http://purl.org/dc/terms/ skos: http://www.w3.org/2004/02/skos/core# prov: http://www.w3.org/ns/prov# mem: http://mementoweb.org/ns# qb: http://purl.org/linked-data/cube# schema: http://schema.org/ doap: http://usefulinc.com/ns/doap# cito: http://purl.org/spar/cito/ as: https://www.w3.org/ns/activitystreams# ldp: http://www.w3.org/ns/ldp# earl: http://www.w3.org/ns/earl# spec: http://www.w3.org/ns/spec# rel: https://www.w3.org/ns/iana/link-relations/relation# odrl: http://www.w3.org/ns/odrl/2/">
    <main>
      <article about="" typeof="schema:Article">
        <div class="head">
          <h1 property="schema:name">Solid Protocol</h1>

          <p id="w3c-state"><a href="https://www.w3.org/standards/types/#reports" rel="rdf:type">Draft Community Group Report</a>, <time datetime="2024-05-12T00:00:00Z">12 May 2024</time></p>

          <details open="">
            <summary>More details about this document</summary>

            <dl id="document-identifier">
              <dt>This version</dt>
              <dd><a href="https://solidproject.org/TR/2024/protocol-20240512" rel="owl:sameAs mem:memento">https://solidproject.org/TR/2024/protocol-20240512</a></dd>
            </dl>

            <dl id="document-latest-published-version">
              <dt>Latest published version</dt>
              <dd><a href="https://solidproject.org/TR/protocol" rel="rel:latest-version">https://solidproject.org/TR/protocol</a></dd>
            </dl>

            <dl id="document-previous-version">
              <dt>Previous version</dt>
              <dd><a href="https://solidproject.org/TR/2022/protocol-20221231" rel="rel:predecessor-version">https://solidproject.org/TR/2022/protocol-20221231</a></dd>
            </dl>

            <dl id="document-editors-draft">
              <dt>Editor’s draft</dt>
              <dd><a href="https://solidproject.org/ED/protocol" rel="rdfs:seeAlso">https://solidproject.org/ED/protocol</a></dd>
            </dl>

            <dl id="document-history">
              <dt>History</dt>
              <dd><a href="https://github.com/solid/specification/commits/main/ED/protocol.html">Commit history</a></dd>
            </dl>

            <dl id="document-timemap">
              <dt>TimeMap</dt>
              <dd><a href="https://solidproject.org/TR/protocol.timemap" rel="mem:timemap">https://solidproject.org/TR/protocol.timemap</a></dd>
            </dl>

            <dl id="document-editors">
              <dt>Editors</dt>
              <dd data-editor-id="46140" id="Sarven-Capadisli"><span about="" rel="schema:creator schema:editor schema:author"><span about="https://csarven.ca/#i" typeof="schema:Person"><a href="https://csarven.ca/" rel="schema:url"><span about="https://csarven.ca/#i" property="schema:name"><span property="schema:givenName">Sarven</span> <span property="schema:familyName">Capadisli</span></span></a></span></span> <span class="contributed">(v0.9, v0.10, v0.11)</span></dd>

              <dd data-editor-id="2017" id="Tim-Berners-Lee"><span about="" rel="schema:editor schema:author"><span about="https://www.w3.org/People/Berners-Lee/card#i" typeof="schema:Person"><a href="https://www.w3.org/People/Berners-Lee/" rel="schema:url"><span about="https://www.w3.org/People/Berners-Lee/card#i" property="schema:name"><span property="schema:givenName">Tim</span> <span property="schema:familyName">Berners-Lee</span></span></a></span></span> <span class="contributed">(v0.9, v0.10, v0.11)</span></dd>

              <dd data-editor-id="38800" id="Kjetil-Kjernsmo"><span about="" rel="schema:editor schema:author"><span about="https://www.kjetil.kjernsmo.net/foaf#me" typeof="schema:Person"><a href="https://kjetil.kjernsmo.net/" rel="schema:url"><span about="https://www.kjetil.kjernsmo.net/foaf#me" property="schema:name"><span property="schema:givenName">Kjetil</span> <span property="schema:familyName">Kjernsmo</span></span></a></span></span> <span class="contributed">(v0.9, v0.10, v0.11)</span></dd>
            </dl>

            <dl id="document-former-editors">
              <dt>Former editors</dt>
              <dd>Ruben Verborgh <span class="contributed">(v0.9, v0.10)</span></dd>
              <dd>Justin-Bingham <span class="contributed">(ED)</span></dd>
              <dd>Dmitri-Zagidulin <span class="contributed">(ED)</span></dd>
            </dl>

            <dl id="document-published">
              <dt>Published</dt>
              <dd><time content="2020-12-16T00:00:00Z" datatype="xsd:dateTime" datetime="2020-12-16T00:00:00Z" property="schema:datePublished">2020-12-16</time></dd>
            </dl>

            <dl id="document-modified">
              <dt>Modified</dt>
              <dd><time content="2024-05-12T00:00:00Z" datatype="xsd:dateTime" datetime="2024-05-12T00:00:00Z" property="schema:dateModified">2024-05-12</time></dd>
            </dl>

            <dl id="document-feedback">
              <dt>Feedback</dt>
              <dd><a href="https://github.com/solid/specification" rel="doap:repository">GitHub solid/specification</a> (<a href="https://github.com/solid/specification/pulls">pull requests</a>, <a href="https://github.com/solid/specification/issues/new">new issue</a>, <a href="https://github.com/solid/specification/issues" rel="doap:bug-database">open issues</a>)</dd>
            </dl>

            <dl id="document-language">
              <dt>Language</dt>
              <dd><span content="en" lang="" property="dcterms:language" xml:lang="">English</span></dd>
            </dl>

            <dl id="document-type">
              <dt>Document Type</dt>
              <dd><a href="http://usefulinc.com/ns/doap#Specification" rel="rdf:type">Specification</a></dd>
            </dl>

            <dl id="document-version">
              <dt>Version</dt>
              <dd><span lang="" property="schema:version" xml:lang="">0.11.0</span></dd>
            </dl>

            <dl id="document-in-reply-to">
              <dt>In Reply To</dt>
              <dd><a href="https://solidproject.org/about" rel="as:inReplyTo">About Solid</a></dd>
            </dl>

            <dl id="document-policy">
              <dt>Policy</dt>
              <dd>
                <dl id="document-policy-offer" rel="odrl:hasPolicy" resource="#document-policy-offer" typeof="odrl:Policy">
                  <dt>Rule</dt>
                  <dd><a about="#document-policy-offer" href="https://www.w3.org/TR/odrl-vocab/#term-Offer" typeof="odrl:Offer">Offer</a></dd>
                  <dt>Unique Identifier</dt>
                  <dd><a href="https://solidproject.org/TR/protocol#document-policy-offer" rel="odrl:uid">https://solidproject.org/TR/protocol#document-policy-offer</a></dd>
                  <dt>Target</dt>
                  <dd><a href="https://solidproject.org/TR/protocol" rel="odrl:target">https://solidproject.org/TR/protocol</a></dd>
                  <dt>Permission</dt>
                  <dd>
                    <dl id="document-permission" rel="odrl:permission" resource="#document-permission" typeof="odrl:Permission">
                      <dt>Assigner</dt>
                      <dd><a href="https://www.w3.org/groups/cg/solid/" rel="odrl:assigner">W3C Solid Community Group</a></dd>
                      <dt>Action</dt>
                      <dd>
                        <ul rel="odrl:action">
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-aggregate" resource="odrl:aggregate">Aggregate</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-archive" resource="odrl:archive">Archive</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-concurrentUse" resource="odrl:concurrentUse">Concurrent Use</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-DerivativeWorks" resource="http://creativecommons.org/ns#DerivativeWorks">Derivative Works</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-derive" resource="odrl:derive">Derive</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-digitize" resource="odrl:digitize">Digitize</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-display" resource="odrl:display">Display</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-Distribution" resource="http://creativecommons.org/ns#Distribution">Distribution</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-index" resource="odrl:index">Index</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-inform" resource="odrl:inform">Inform</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-install" resource="odrl:install">Install</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-Notice" resource="http://creativecommons.org/ns#Notice">Notice</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-present" resource="odrl:present">Present</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-print" resource="odrl:print">Print</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-read" resource="odrl:read">Read</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-reproduce" resource="odrl:reproduce">Reproduce</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-Reproduction" resource="http://creativecommons.org/ns#Reproduction">Reproduction</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-stream" resource="odrl:stream">Stream</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-synchronize" resource="odrl:synchronize">Synchronize</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-textToSpeech" resource="odrl:textToSpeech">Text-to-speech</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-transform" resource="odrl:transform">Transform</a></li>
                          <li><a href="https://www.w3.org/TR/odrl-vocab/#term-translate" resource="odrl:translate">Translate</a></li>
                        </ul>
                      </dd>
                    </dl>
                  </dd>
                </dl>
              </dd>
            </dl>
          </details>

          <p class="copyright" rel="dcterms:rights" resource="#document-rights"><span property="dcterms:description"><a href="https://www.w3.org/policies/#copyright">Copyright</a> © 2019–2024 the Contributors to Solid Protocol, Version 0.11.0, published by the <a about="" href="https://www.w3.org/groups/cg/solid/" rel="schema:publisher"><span property="schema:name">Solid Community Group</span></a> under the <a about="" href="https://www.w3.org/community/about/agreements/cla/" rel="schema:license">W3C Community Contributor License Agreement (CLA)</a>. A human-readable <a href="https://www.w3.org/community/about/agreements/cla-deed/">summary</a> is available.</span></p>

          <hr title="Separator for header" />
        </div>

        <div datatype="rdf:HTML" id="content" property="schema:description">
          <section id="abstract"><a class="self-link" href="#abstract"></a>
            <h2>Abstract</h2>
            <div datatype="rdf:HTML" property="schema:abstract">
              <p>This document connects a set of specifications that, together, provide applications with secure and permissioned access to externally stored data in an interoperable way.</p>
            </div>
          </section>

          <section id="sotd" inlist="" rel="schema:hasPart" resource="#sotd"><a class="self-link" href="#sotd"></a>
            <h2 property="schema:name">Status of This Document</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>This report was published by the <a href="https://www.w3.org/groups/cg/solid/">Solid Community Group</a>. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a> there is a limited opt-out and other conditions apply. Learn more about <a href="https://www.w3.org/community/">W3C Community and Business Groups</a>.</p>
            </div>
          </section>

          <nav id="toc">
            <h2>Table of Contents</h2>
            <div>
              <ol class="toc">
                <li class="tocline">
                  <a class="tocxref" href="#abstract"><bdi class="secno"></bdi> <span>Abstract</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#sotd"><bdi class="secno"></bdi> <span>Status of This Document</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#introduction"><bdi class="secno">1.</bdi> <span>Introduction</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#terminology"><bdi class="secno">1.1</bdi> <span>Terminology</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#namespaces"><bdi class="secno">1.2</bdi> <span>Namespaces</span></a></li>
                    <li class="tocline">
                      <a class="tocxref" href="#conformance"><bdi class="secno">1.3</bdi> <span>Conformance</span></a>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#normative-informative-content"><bdi class="secno">1.3.1</bdi> <span>Normative and Informative Content</span></a></li>
                        <li class="tocline"><a class="tocxref" href="#specification-category"><bdi class="secno">1.3.2</bdi> <span>Specification Category</span></a></li>
                        <li class="tocline"><a class="tocxref" href="#classes-of-products"><bdi class="secno">1.3.3</bdi> <span>Classes of Products</span></a></li>
                        <li class="tocline"><a class="tocxref" href="#interoperability"><bdi class="secno">1.3.4</bdi> <span>Interoperability</span></a></li>
                      </ol>
                    </li>
                    <li class="tocline">
                      <a class="tocxref" href="#relations"><bdi class="secno">1.4</bdi> <span>Relations</span></a>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#relationship-to-ldp"><bdi class="secno">1.4.1</bdi> <span>Relationship to LDP</span></a></li>
                      </ol>
                    </li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#http"><bdi class="secno">2.</bdi> <span>Hypertext Transfer Protocol</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#http-server"><bdi class="secno">2.1</bdi> <span>HTTP Server</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#http-client"><bdi class="secno">2.2</bdi> <span>HTTP Client</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#uri"><bdi class="secno">3.</bdi> <span>Uniform Resource Identifier</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#uri-slash-semantics"><bdi class="secno">3.1</bdi> <span>URI Slash Semantics</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#uri-persistence"><bdi class="secno">3.2</bdi> <span>URI Persistence</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#resources"><bdi class="secno">4.</bdi> <span>Resources</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#storage-resource"><bdi class="secno">4.1</bdi> <span>Storage Resource</span></a></li>
                    <li class="tocline">
                      <a class="tocxref" href="#resource-containment"><bdi class="secno">4.2</bdi> <span>Resource Containment</span></a>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#contained-resource-metadata"><bdi class="secno">4.2.1</bdi> <span>Contained Resource Metadata</span></a></li>
                      </ol>
                    </li>
                    <li class="tocline">
                      <a class="tocxref" href="#auxiliary-resources"><bdi class="secno">4.3</bdi> <span>Auxiliary Resources</span></a>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#auxiliary-resources-web-access-control"><bdi class="secno">4.3.1</bdi> <span>Web Access Control</span></a></li>
                        <li class="tocline"><a class="tocxref" href="#auxiliary-resources-description-resource"><bdi class="secno">4.3.2</bdi> <span>Description Resource</span></a></li>
                      </ol>
                    </li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#reading-writing-resources"><bdi class="secno">5.</bdi> <span>Reading and Writing Resources</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#resource-type-heuristics"><bdi class="secno">5.1</bdi> <span>Resource Type Heuristics</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#reading-resources"><bdi class="secno">5.2</bdi> <span>Reading Resources</span></a></li>
                    <li class="tocline">
                      <a class="tocxref" href="#writing-resources"><bdi class="secno">5.3</bdi> <span>Writing Resources</span></a>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#n3-patch"><bdi class="secno">5.3.1</bdi> <span>Modifying Resources Using N3 Patches</span></a></li>
                      </ol>
                    </li>
                    <li class="tocline"><a class="tocxref" href="#deleting-resources"><bdi class="secno">5.4</bdi> <span>Deleting Resources</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#resource-representations"><bdi class="secno">5.5</bdi> <span>Resource Representations</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#constraints-problem-details"><bdi class="secno">5.6</bdi> <span>Constraints and Problem Details</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#linked-data-notifications"><bdi class="secno">6.</bdi> <span>Linked Data Notifications</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#live-update"><bdi class="secno">7.</bdi> <span>Live Update</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#notifications-protocol"><bdi class="secno">7.1</bdi> <span>Solid Notifications Protocol</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#cors"><bdi class="secno">8.</bdi> <span>Cross-Origin Resource Sharing</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#cors-server"><bdi class="secno">8.1</bdi> <span>CORS Server</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#identity"><bdi class="secno">9.</bdi> <span>Identity</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#webid"><bdi class="secno">9.1</bdi> <span>WebID</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#authentication"><bdi class="secno">10.</bdi> <span>Authentication</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#solid-oidc"><bdi class="secno">10.1</bdi> <span>Solid-OIDC</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#webid-tls"><bdi class="secno">10.2</bdi> <span>WebID-TLS</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#authorization"><bdi class="secno">11.</bdi> <span>Authorization</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#web-access-control"><bdi class="secno">11.1</bdi> <span>Web Access Control</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#access-control-policy"><bdi class="secno">11.2</bdi> <span>Access Control Policy</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#http-definitions"><bdi class="secno">12.</bdi> <span>HTTP Definitions</span></a>
                  <ol>
                    <li class="tocline">
                      <a class="tocxref" href="#http-headers"><bdi class="secno">12.1</bdi> <span>HTTP Headers</span></a>
                      <ol>
                        <li class="tocline"><a class="tocxref" href="#accept-put"><bdi class="secno">12.1.1</bdi> <span>The Accept-Put Response Header</span></a></li>
                      </ol>
                    </li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#considerations"><bdi class="secno">13.</bdi> <span>Considerations</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#security-considerations"><bdi class="secno">13.1</bdi> <span>Security Considerations</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#privacy-considerations"><bdi class="secno">13.2</bdi> <span>Privacy Considerations</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#accessibility-considerations"><bdi class="secno">13.3</bdi> <span>Accessibility Considerations</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#internationalization-considerations"><bdi class="secno">13.4</bdi> <span>Internationalization Considerations</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#security-privacy-review"><bdi class="secno">13.5</bdi> <span>Security and Privacy Review</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#societal-impact-review"><bdi class="secno">13.6</bdi> <span>Societal Impact Review</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#changelog"><bdi class="secno">A.</bdi> <span>Changelog</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#acknowledgements"><bdi class="secno">B.</bdi> <span>Acknowledgements</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#references"><bdi class="secno">C.</bdi> <span>References</span></a>
                  <ol>
                    <li class="tocline"><a class="tocxref" href="#normative-references"><bdi class="secno">C.1</bdi> <span>Normative References</span></a></li>
                    <li class="tocline"><a class="tocxref" href="#informative-references"><bdi class="secno">C.2</bdi> <span>Informative References</span></a></li>
                  </ol>
                </li>
              </ol>
            </div>
          </nav>

          <section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction"><a class="self-link" href="#introduction"></a>
            <h2 property="schema:name">Introduction</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p><em>This section is non-normative.</em></p>

              <p>The aims of the Solid project are in line with those of the Web itself: empowerment towards <q cite="https://www.w3.org/TR/ethical-web-principles/">an equitable, informed and interconnected society</q>. Solid adds to existing Web standards to realise a space where individuals can maintain their autonomy, control their data and privacy, and choose applications and services to fulfil their needs.</p>

              <p>The Solid ecosystem encapsulates a set of specifications that are guided by the principles we have adopted and also the priority of our values. We acknowledge that every technical decision has ethical implications both for the end user (short-term) as well as society (long-term). To contribute towards a net positive social benefit, we use the <cite><a href="https://www.w3.org/TR/ethical-web-principles/" rel="cito:citesForInformation">Ethical Web Principles</a></cite> [<cite><a class="bibref" href="#bib-ethical-web-principles">ETHICAL-WEB-PRINCIPLES</a></cite>] to orient ourselves. The consensus on the technical designs are informed by common use cases, implementation experience, and use.</p>

              <p>An overarching design goal of the Solid ecosystem is to be evolvable and to provide fundamental affordances for decentralised Web applications for information exchange in a way that is secure and privacy respecting. In this environment, actors allocate identifiers for their content, shape and store data where they have access to, set access controls, and use preferred applications and services to achieve them.</p>

              <p>The general architectural principles of Solid specifications are borrowed from the <cite><a href="https://www.w3.org/TR/webarch/" rel="cito:citesForInformation">Architecture of the World Wide Web</a></cite> [<cite><a class="bibref" href="#bib-webarch">WEBARCH</a></cite>]. The components as described in each specification may evolve independently – according to the principle of orthogonality in order to increase the flexibility and robustness of the Solid ecosystem. With that, the specifications are loosely coupled and indicate which features overlap with those governed by another specification. Extensibility as well as variability also are taken into account in each specification.</p>

              <p>The specifications in the ecosystem describe how Solid servers and clients can be interoperable by using Web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, and query interfaces.</p>

              <p>The specifications are accompanied with supplemental documents, such as <em>Primers</em> and <em>Best Practices and Guidelines</em> to help implementers to form a well-rounded understanding of the Solid ecosystem as well as ways to improve their implementations.</p>

              <p>This specification is for:</p>

              <ul about="" rel="schema:audience">
                <li>Resource <a href="http://data.europa.eu/esco/occupation/a7c1d23d-aeca-4bee-9a08-5993ed98b135">server developers</a> that want to enable clients to send and retrieve information;</li>
                <li><a href="http://data.europa.eu/esco/occupation/c40a2919-48a9-40ea-b506-1f34f693496d">Application developers</a> that want to implement a client to perform operations on resources.</li>
              </ul>

              <section id="terminology" inlist="" rel="schema:hasPart" resource="#terminology" typeof="skos:ConceptScheme"><a class="self-link" href="#terminology"></a>
                <h3 property="schema:name skos:prefLabel">Terminology</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>

                  <p property="skos:definition">The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification.</p>

                  <span rel="skos:hasTopConcept"><span resource="#storage"></span><span resource="#solid-app"></span><span resource="#uniform-resource-identifier"></span><span resource="#resource"></span><span resource="#container-resource"></span><span resource="#root-container"></span><span resource="#resource-metadata"></span><span resource="#agent"></span><span resource="#owner"></span><span resource="#origin"></span><span resource="#read-operation"></span><span resource="#write-operation"></span><span resource="#append-operation"></span></span>

                  <dl>
                    <dt about="#storage" property="skos:prefLabel" typeof="skos:Concept"><dfn id="storage"><a class="self-link" href="#storage"></a>storage</dfn></dt>
                    <dd about="#storage" property="skos:definition">A storage is a space of URIs that affords agents controlled access to resources.</dd>

                    <dt about="#solid-app" property="skos:prefLabel" typeof="skos:Concept"><dfn id="solid-app"><a class="self-link" href="#solid-app"></a>Solid app</dfn></dt>
                    <dd about="#solid-app" property="skos:definition">A Solid app is an application that reads or writes data from one or more <a href="#storage">storages</a>.</dd>

                    <dt about="#uniform-resource-identifier" property="skos:prefLabel" typeof="skos:Concept"><dfn id="uniform-resource-identifier"><a class="self-link" href="#uniform-resource-identifier"></a>URI</dfn></dt>
                    <dd about="#uniform-resource-identifier" property="skos:definition">A <dfn>Uniform Resource Identifier</dfn> (<abbr title="Uniform Resource Identifier">URI</abbr>) provides the means for identifying resources [<cite><a class="bibref" href="#bib-rfc3986">RFC3986</a></cite>].</dd>

                    <dt about="#resource" property="skos:prefLabel" typeof="skos:Concept"><dfn id="resource"><a class="self-link" href="#resource"></a>resource</dfn></dt>
                    <dd about="#resource" property="skos:definition">A resource is the target of an HTTP request identified by a URI [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>].</dd>

                    <dt about="#container-resource" property="skos:prefLabel" typeof="skos:Concept"><dfn id="container-resource"><a class="self-link" href="#container-resource"></a>container resource</dfn></dt>
                    <dd about="#container-resource" property="skos:definition">A container resource is a hierarchical collection of resources that contains other resources, including containers.</dd>

                    <dt about="#root-container" property="skos:prefLabel" typeof="skos:Concept"><dfn id="root-container"><a class="self-link" href="#root-container"></a>root container</dfn></dt>
                    <dd about="#root-container" property="skos:definition">A root container is a container resource that is at the highest level of the collection hierarchy.</dd>

                    <dt about="#resource-metadata" property="skos:prefLabel" typeof="skos:Concept"><dfn id="resource-metadata"><a class="self-link" href="#resource-metadata"></a>resource metadata</dfn></dt>
                    <dd about="#resource-metadata" property="skos:definition">Resource metadata encompasses data about resources described by means of RDF statements [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>].</dd>

                    <dt about="#agent" property="skos:prefLabel" typeof="skos:Concept"><dfn id="agent"><a class="self-link" href="#agent"></a>agent</dfn></dt>
                    <dd about="#agent" property="skos:definition">An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [<cite><a class="bibref" href="#bib-webid">WEBID</a></cite>].</dd>

                    <dt about="#owner" property="skos:prefLabel" typeof="skos:Concept"><dfn id="owner"><a class="self-link" href="#owner"></a>owner</dfn></dt>
                    <dd about="#owner" property="skos:definition">An owner is a person or a social entity that is considered to have the rights and responsibilities of a storage. An owner is identified by a URI, and implicitly has control over all resources in a storage. An owner is first set at storage provisioning time and can be changed.</dd>

                    <dt about="#origin" property="skos:prefLabel" typeof="skos:Concept"><dfn id="origin"><a class="self-link" href="#origin"></a>origin</dfn></dt>
                    <dd about="#origin" property="skos:definition">An origin indicates where an HTTP request originates from [<cite><a class="bibref" href="#bib-rfc6454">RFC6454</a></cite>].</dd>

                    <dt about="#read-operation" property="skos:prefLabel" typeof="skos:Concept"><dfn id="read-operation"><a class="self-link" href="#read-operation"></a>read operation</dfn></dt>
                    <dd about="#read-operation" property="skos:definition">A read operation entails that information about a resource’s existence or its description can be known. [<a href="https://github.com/solid/specification/issues/149#issue-568433265" rel="cito:citesAsSourceDocument">Source</a>]</dd>

                    <dt about="#write-operation" property="skos:prefLabel" typeof="skos:Concept"><dfn id="write-operation"><a class="self-link" href="#write-operation"></a>write operation</dfn></dt>
                    <dd about="#write-operation" property="skos:definition">A write operation entails that information about resources can be created or removed. [<a href="https://github.com/solid/specification/issues/126#issuecomment-569920473" rel="cito:citesAsSourceDocument">Source</a>]</dd>

                    <dt about="#append-operation" property="skos:prefLabel" typeof="skos:Concept"><dfn id="append-operation"><a class="self-link" href="#append-operation"></a>append operation</dfn></dt>
                    <dd about="#append-operation" property="skos:definition">An append operation entails that information can be added but not removed. [<a href="https://github.com/solid/specification/issues/118#issuecomment-569648485" rel="cito:citesAsSourceDocument">Source</a>]</dd>
                  </dl>
                </div>
              </section>

              <section id="namespaces" inlist="" rel="schema:hasPart" resource="#namespaces"><a class="self-link" href="#namespaces"></a>
                <h3 property="schema:name">Namespaces</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <table>
                    <caption>Prefixes and Namespaces</caption>
                    <thead>
                      <tr>
                        <th>Prefix</th>
                        <th>Namespace</th>
                        <th>Description</th>
                      </tr>
                    </thead>
                    <tbody>
                      <tr>
                        <td><code>rdf</code></td>
                        <td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td>
                        <td>[<cite><a class="bibref" href="#bib-rdf-schema">rdf-schema</a></cite>]</td>
                      </tr>
                      <tr>
                        <td><code>ldp</code></td>
                        <td>http://www.w3.org/ns/ldp#</td>
                        <td>[<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>]</td>
                      </tr>
                      <tr>
                        <td><code>solid</code></td>
                        <td>http://www.w3.org/ns/solid/terms#</td>
                        <td>Solid Terms</td>
                      </tr>
                      <tr>
                        <td><code>pim</code></td>
                        <td>http://www.w3.org/ns/pim/space#</td>
                        <td>Workspace Ontology</td>
                      </tr>
                      <tr>
                        <td><code>acl</code></td>
                        <td>http://www.w3.org/ns/auth/acl#</td>
                        <td>ACL Ontology</td>
                      </tr>
                      <tr>
                        <td><code>dcterms</code></td>
                        <td>http://purl.org/dc/terms/</td>
                        <td>[<cite><a class="bibref" href="#bib-dc-terms">DC-TERMS</a></cite>]</td>
                      </tr>
                      <tr>
                        <td><code>stat</code></td>
                        <td>http://www.w3.org/ns/posix/stat</td>
                        <td>POSIX File Status</td>
                      </tr>
                    </tbody>
                  </table>
                </div>
              </section>

              <section id="conformance" inlist="" rel="schema:hasPart" resource="#conformance"><a class="self-link" href="#conformance"></a>
                <h3 property="schema:name">Conformance</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>This section describes the <span about="" rel="spec:conformance" resource="#conformance">conformance model of the Solid Protocol</span>.</p>

                  <section id="normative-informative-content" inlist="" rel="schema:hasPart" resource="#normative-informative-content"><a class="self-link" href="#normative-informative-content"></a>
                    <h4 property="schema:name">Normative and Informative Content</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p id="normative-informative-sections"><a class="self-link" href="#normative-informative-sections"></a>All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.</p>

                      <p id="requirement-levels"><a class="self-link" href="#requirement-levels"></a>The key words “<span rel="dcterms:subject" resource="spec:MUST">MUST</span>”, “<span rel="dcterms:subject" resource="spec:MUSTNOT">MUST NOT</span>”, “<span rel="dcterms:subject" resource="spec:SHOULD">SHOULD</span>”, and “<span rel="dcterms:subject" resource="spec:MAY">MAY</span>” are to be interpreted as described in <a href="https://www.rfc-editor.org/info/bcp14">BCP 14</a> [<cite><a class="bibref" href="#bib-rfc2119">RFC2119</a></cite>] [<cite><a class="bibref" href="#bib-rfc8174">RFC8174</a></cite>] when, and only when, they appear in all capitals, as shown here.</p>

                      <p id="advisement-levels"><a class="self-link" href="#advisement-levels"></a>The key words “<span rel="dcterms:subject" resource="spec:StronglyEncouraged">strongly encouraged</span>”, “<span rel="dcterms:subject" resource="spec:StronglyDiscouraged">strongly discouraged</span>”, “<span rel="dcterms:subject" resource="spec:Encouraged">encouraged</span>", “<span rel="dcterms:subject" resource="spec:Discouraged">discouraged</span>", “<span rel="dcterms:subject" resource="spec:Can">can</span>", “<span rel="dcterms:subject" resource="spec:Cannot">cannot</span>”, “<span rel="dcterms:subject" resource="spec:Could">could</span>”, “<span rel="dcterms:subject" resource="spec:CouldNot">could not</span>”, “<span rel="dcterms:subject" resource="spec:Might">might</span>”, and “<span rel="dcterms:subject" resource="spec:MightNot">might not</span>” are used for non-normative content.</p>
                    </div>
                  </section>

                  <section id="specification-category" inlist="" rel="schema:hasPart" resource="#specification-category" typeof="skos:ConceptScheme"><a class="self-link" href="#specification-category"></a>
                    <h4 property="schema:name skos:prefLabel">Specification Category</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p property="skos:definition">The <span about="" rel="spec:specificationCategory" resource="#specification-category">Solid Protocol</span> identifies the following <cite><a href="https://www.w3.org/TR/spec-variability/#spec-cat" rel="dcterms:subject" resource="spec:SpecificationCategory">Specification Category</a></cite> to distinguish the types of conformance: <span rel="skos:hasTopConcept" resource="spec:API">API</span>, <span rel="skos:hasTopConcept" resource="spec:NotationSyntax">notation/syntax</span>, <span rel="skos:hasTopConcept" resource="spec:SetOfEvents">set of events</span>, <span rel="skos:hasTopConcept" resource="spec:ProcessorBehaviour">processor behaviour</span>, <span rel="skos:hasTopConcept" resource="spec:Protocol">protocol</span>.</p>
                    </div>
                  </section>

                  <section id="classes-of-products" inlist="" rel="schema:hasPart" resource="#classes-of-products" typeof="skos:ConceptScheme"><a class="self-link" href="#classes-of-products"></a>
                    <h4 property="schema:name skos:prefLabel">Classes of Products</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p property="skos:definition">The <span about="" rel="spec:classesOfProducts" resource="#classes-of-products">Solid Protocol</span> identifies the following <cite><a href="https://www.w3.org/TR/qaframe-spec/#cop-def" rel="dcterms:subject" resource="spec:ClassesOfProducts">Classes of Products</a></cite> for conforming implementations. These products are referenced throughout this specification.</p>

                      <span rel="skos:hasTopConcept"><span resource="#Server"></span><span resource="#Client"></span></span>

                      <dl>
                        <dt about="#Server" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="Server"><a class="self-link" href="#Server"></a>Server</dfn></dt>
                        <dd about="#Server" property="skos:definition">A <a href="#http-server" rel="rdfs:seeAlso">server</a> that builds on HTTP <cite>server</cite> [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>] and [<cite><a class="bibref" href="#bib-rfc9112">RFC9112</a></cite>] by defining media types, HTTP header fields, and the behaviour of resources, as identified by link relations.</dd>
                        <dt about="#Client" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:Consumer" typeof="skos:Concept"><dfn id="Client"><a class="self-link" href="#Client"></a>Client</dfn></dt>
                        <dd about="#Client" property="skos:definition">A <a href="#http-client" rel="rdfs:seeAlso">client</a> that builds on HTTP <cite>client</cite> [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>], [<cite><a class="bibref" href="#bib-rfc9112">RFC9112</a></cite>], and [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>] by defining behaviour in terms of fetching across the platform.</dd>
                      </dl>
                    </div>
                  </section>

                  <section id="interoperability" inlist="" rel="schema:hasPart" resource="#interoperability"><a class="self-link" href="#interoperability"></a>
                    <h4 property="schema:name skos:prefLabel">Interoperability</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p id="interoperability-server-client"><a class="self-link" href="#interoperability-server-client"></a>Interoperability of implementations for <a href="#Server" rel="rdfs:seeAlso">servers</a> and <a href="#Client" rel="rdfs:seeAlso">clients</a> is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to this specification.</p>
                    </div>
                  </section>
                </div>
              </section>

              <section id="relations" inlist="" rel="schema:hasPart" resource="#relations"><a class="self-link" href="#relations"></a>
                <h3 property="schema:name">Relations</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>

                  <section id="relationship-to-ldp" inlist="" rel="schema:hasPart" resource="#relationship-to-ldp"><a class="self-link" href="#relationship-to-ldp"></a>
                    <h4 property="schema:name">Relationship to LDP</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p><em>This section is non-normative.</em></p>

                      <p>The <a href="https://solidproject.org/TR/protocol" rel="cito:discusses">Solid Protocol</a> and the <a href="https://www.w3.org/TR/ldp/" rel="cito:discusses">Linked Data Platform</a> (<abbr title="Linked Data Platform">LDP</abbr>) [<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>] both use relative referencing of URIs [<cite><a class="bibref" href="#bib-rfc3986">RFC3986</a></cite>].</p>

                      <p>As HTTP clients assign a URI to a resource when using <code>PUT</code> and <code>PATCH</code>, relative references in representation content are deterministic in both the Solid Protocol and LDP.</p>

                      <p>LDP does not specify URI patterns for resources when using the <code>POST</code> method, e.g., <code>POST http://example.org/foo/</code> may result in creating a resource with URI <code>http://example.org/foo/bar</code>, <code>http://example.org/baz/qux/quxx</code>, <code>http://example.org/{uuid}</code> or something else. In Solid Protocol, the URI of a new resource resulting from, e.g., <code>POST http://example.org/foo/</code>, is in context of the request URI, and therefore <code>http://example.org/foo/bar</code> will be created, and it is not possible to construct the new URI besides under the direct hierarchy of <code>http://example.org/foo/</code>.</p>

                      <p>Solid Protocol's <a href="#Server">server</a> behaviour in that regard is compatible with LDP even if only <code>ldp:Container</code> is advertised in the HTTP <code>Link</code> header field of the request URI, i.e., <code>http://example.org/foo/</code> as the target URI of <code>POST</code>. Thus, it is possible to have a Solid Protocol server as a particular specialisation of LDP with respect to behaviours around <code>POST</code> to containers. Clients that are interoperable with LDP servers would also be interoperable with Solid Protocol servers with respect to relative referencing. Although LDP servers cannot guarantee the URI pattern resulting from <code>POST</code> requests, the fact that Solid Protocol servers can does not impact interoperability between Solid Protocol servers and LDP clients.</p>

                      <p>Solid Protocol <a href="#Client">clients</a> may not fully interoperate with LDP servers, e.g., it is possible for an LDP server implementation to assign URIs to new resources that are not compatible with Solid Protocol. An LDP server needs to also conform to Solid Protocol server requirements in order to participate in the Solid ecosystem.</p>
                    </div>
                  </section>
                </div>
              </section>
            </div>
          </section>

          <section id="http" inlist="" rel="schema:hasPart" resource="#http"><a class="self-link" href="#http"></a>
            <h2 property="schema:name">Hypertext Transfer Protocol</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>Solid <a href="#Server" rel="dcterms:subject">servers</a> and <a href="#Client" rel="dcterms:subject">clients</a> need to exchange data securely over the Internet, and they do so using the HTTP Web standard. This section describes in detail which parts of HTTP must be implemented by clients and servers.</p>

              <section id="http-server" inlist="" rel="schema:hasPart" resource="#http-server"><a class="self-link" href="#http-server"></a>
                <h3 property="schema:name">HTTP Server</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><span about="" id="server-http" rel="spec:requirement" resource="#server-http"><a class="self-link" href="#server-http"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP Semantics</cite> [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>].</span></span> <span about="" id="server-caching" rel="spec:requirement" resource="#server-caching"><a class="self-link" href="#server-caching"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> conform to <cite>HTTP Caching</cite> [<cite><a class="bibref" href="#bib-rfc9111">RFC9111</a></cite>].</span></span> <span about="" id="server-http-11" rel="spec:requirement" resource="#server-http-11"><a class="self-link" href="#server-http-11"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP/1.1</cite> [<cite><a class="bibref" href="#bib-rfc9112">RFC9112</a></cite>].</span></span> <span about="" id="server-http-2" rel="spec:requirement" resource="#server-http-2"><a class="self-link" href="#server-http-2"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> conform to <cite>HTTP/2</cite> [<cite><a class="bibref" href="#bib-rfc9113">RFC9113</a></cite>].</span></span></p>

                  <p><span about="" id="server-tls-https" rel="spec:requirement" resource="#server-tls-https"><a class="self-link" href="#server-tls-https"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> use TLS connections through the <code>https</code> URI scheme in order to secure the communication with clients.</span></span> <span about="" id="server-tls-https-redirect" rel="spec:requirement" resource="#server-tls-https-redirect"><a class="self-link" href="#server-tls-https-redirect"></a><span property="spec:statement">When both <code>http</code> and <code>https</code> URI schemes are supported, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> redirect all <code>http</code> URIs to their <code>https</code> counterparts using a response with a <code>301</code> status code and a <code>Location</code> header field.</span></span></p>

                  <p about="" id="server-unauthenticated" rel="spec:requirement" resource="#server-unauthenticated"><a class="self-link" href="#server-unauthenticated"></a><span property="spec:statement">When a client does not provide valid credentials when requesting a resource that requires it (see <a href="#webid">WebID</a>), <span rel="spec:requirementSubject" resource="#Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> send a response with a <code>401</code> status code (unless <code>404</code> is preferred for security reasons).</span></p>

                  <p about="" id="server-content-type-includes" rel="spec:requirement" resource="#server-content-type-includes"><a class="self-link" href="#server-content-type-includes"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> generate a <code>Content-Type</code> header field in a message that contains content.</span></p>

                  <p about="" id="server-content-type-missing" rel="spec:requirement" resource="#server-content-type-missing"><a class="self-link" href="#server-content-type-missing"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> reject <code>PUT</code>, <code>POST</code>, and <code>PATCH</code> requests that contain content but lack the <code>Content-Type</code> header field, with a status code of <code>400</code>.</span> [<a href="https://github.com/solid/specification/issues/70#issuecomment-547924171" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/660#issue-2319265317" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>

              <section id="http-client" inlist="" rel="schema:hasPart" resource="#http-client"><a class="self-link" href="#http-client"></a>
                <h3 property="schema:name">HTTP Client</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><span about="" id="client-http" rel="spec:requirement" resource="#client-http"><a class="self-link" href="#client-http"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP Semantics</cite> [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>].</span></span> <span about="" id="client-caching" rel="spec:requirement" resource="#client-caching"><a class="self-link" href="#client-caching"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> conform to <cite>HTTP Caching</cite> [<cite><a class="bibref" href="#bib-rfc9111">RFC9111</a></cite>].</span></span> <span about="" id="client-http-11" rel="spec:requirement" resource="#client-http-11"><a class="self-link" href="#client-http-11"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to <cite>HTTP/1.1</cite> [<cite><a class="bibref" href="#bib-rfc9112">RFC9112</a></cite>].</span></span> <span about="" id="client-http-2" rel="spec:requirement" resource="#client-http-2"><a class="self-link" href="#client-http-2"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> conform to <cite>HTTP/2</cite> [<cite><a class="bibref" href="#bib-rfc9113">RFC9113</a></cite>].</span></span></p>

                  <p about="" id="client-authentication-different-credentials" rel="spec:requirement" resource="#client-authentication-different-credentials"><a class="self-link" href="#client-authentication-different-credentials"></a><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="#Client">client</span> receives a response with a <code>403</code> or <code>404</code> status code, the client <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> repeat the request with different credentials.</span></p>

                  <p about="" id="client-content-type-includes" rel="spec:requirement" resource="#client-content-type-includes"><a class="self-link" href="#client-content-type-includes"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> use the <code>Content-Type</code> HTTP header field in <code>PUT</code>, <code>POST</code>, and <code>PATCH</code> requests that contain content [<cite><a class="bibref" href="#bib-rfc9110">RFC9110</a></cite>].</span> [<a href="https://github.com/solid/specification/issues/70#issuecomment-547924171" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/660#issue-2319265317" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>
            </div>
          </section>

          <section id="uri" inlist="" rel="schema:hasPart" resource="#uri"><a class="self-link" href="#uri"></a>
            <h2 property="schema:name">Uniform Resource Identifier</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <div class="note" id="storage-owner-uri-ownership" inlist="" rel="schema:hasPart" resource="#storage-owner-uri-ownership"><a class="self-link" href="#storage-owner-uri-ownership"></a>
                <h3 property="schema:name"><span>Note</span>: Storage Owner and URI Ownership</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>This specification does not describe the relationship between a storage <q>owner</q> and Web architecture’s <cite><a href="https://www.w3.org/TR/webarch/#uri-ownership">URI ownership</a></cite> [<cite><a class="bibref" href="#bib-webarch">WEBARCH</a></cite>].</p>
                </div>
              </div>

              <section id="uri-slash-semantics" inlist="" rel="schema:hasPart" resource="#uri-slash-semantics"><a class="self-link" href="#uri-slash-semantics"></a>
                <h3 property="schema:name">URI Slash Semantics</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p id="uri-slashes-hierarchical-identifier"><a class="self-link" href="#uri-slashes-hierarchical-identifier"></a>The slash (<code>/</code>) character in the URI path indicates hierarchical relationship segments, and enables relative referencing [<cite><a class="bibref" href="#bib-rfc3986">RFC3986</a></cite>]. The semantics of the slash character is shared by servers and clients. Paths ending with a slash denote a container resource. [<a href="https://github.com/solid/specification/issues/35#issuecomment-547949014" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-uri-trailing-slash-distinct" rel="spec:requirement" resource="#server-uri-trailing-slash-distinct"><a class="self-link" href="#server-uri-trailing-slash-distinct"></a><span property="spec:statement">If two URIs differ only in the trailing slash, and the <span rel="spec:requirementSubject" resource="#Server">server</span> has associated a resource with one of them, then the other URI <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> correspond to another resource.</span></span> <span about="" id="server-uri-redirect-differing" rel="spec:requirement" resource="#server-uri-redirect-differing"><a class="self-link" href="#server-uri-redirect-differing"></a><span property="spec:statement">Instead, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> respond to requests for the latter URI with a 301 redirect to the former.</span></span> [<a href="https://github.com/solid/specification/issues/107#issuecomment-567482817" rel="cito:citesAsSourceDocument">Source</a>]. <span about="" id="server-authorization-redirect" rel="spec:requirement" resource="#server-authorization-redirect"><a class="self-link" href="#server-authorization-redirect"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> authorize prior to this optional redirect.</span></span> [<a href="https://github.com/solid/specification/issues/107#issuecomment-567454889" rel="cito:citesAsSourceDocument">Source</a>].</p>
                </div>
              </section>

              <section id="uri-persistence" inlist="" rel="schema:hasPart" resource="#uri-persistence"><a class="self-link" href="#uri-persistence"></a>
                <h3 property="schema:name">URI Persistence</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>

                  <p>Servers should not re-use URIs, regardless of the mechanism by which resources are created. Certain specific cases exist where URIs may be reinstated when it identifies the same resource, but only when consistent with Web architecture’s <cite><a href="https://www.w3.org/TR/webarch/#URI-persistence">URI persistence</a></cite> [<cite><a class="bibref" href="#bib-webarch">WEBARCH</a></cite>]. [<a href="https://github.com/solid/specification/issues/46#issuecomment-589619372" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <div class="note" id="uri-reuse" inlist="" rel="schema:hasPart" resource="#uri-reuse"><a class="self-link" href="#uri-reuse"></a>
                    <h4 property="schema:name"><span>Note</span>: URI Reuse</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p about="" id="uri-reuse-disabling" rel="spec:advisement" resource="#uri-reuse-disabling"><a class="self-link" href="#uri-reuse-disabling"></a><span property="spec:statement">Servers that wish to disable URI re-use <span rel="spec:advisementLevel" resource="spec:Might">might</span> want to use the <code>410</code> status code.</span></p>
                    </div>
                  </div>
                </div>
              </section>
            </div>
          </section>

          <section id="resources" inlist="" rel="schema:hasPart" resource="#resources"><a class="self-link" href="#resources"></a>
            <h2 property="schema:name">Resources</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <section id="storage-resource" inlist="" rel="schema:hasPart" resource="#storage-resource"><a class="self-link" href="#storage-resource"></a>
                <h3 property="schema:name">Storage Resource</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p about="" id="server-storage" rel="spec:requirement" resource="#server-storage"><a class="self-link" href="#server-storage"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> provide one or more <a href="#storage">storages</a>. The storage resource (<code>pim:Storage</code>) is the root container for all of its contained resources (see <a href="#resource-containment">Resource Containment</a>).</span></p>

                  <p about="" id="server-storage-nonoverlapping" rel="spec:requirement" resource="#server-storage-nonoverlapping"><a class="self-link" href="#server-storage-nonoverlapping"></a><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="#Server">server</span> supports multiple storages, the URIs <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be allocated to non-overlapping space.</span></p>

                  <p about="" id="server-link-storage" rel="spec:requirement" resource="#server-link-storage"><a class="self-link" href="#server-link-storage"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> advertise the storage resource by including the HTTP <code>Link</code> header field with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code> when responding to storage’s request URI.</span></p>

                  <p about="" id="client-link-storage" rel="spec:requirement" resource="#client-link-storage"><a class="self-link" href="#client-link-storage"></a>Clients can determine a resource is of type storage by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking for the <code>Link</code> header field with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code>.</p>

                  <p about="" id="client-storage-discovery" rel="spec:requirement" resource="#client-storage-discovery"><a class="self-link" href="#client-storage-discovery"></a>Clients can determine the storage of a resource by moving up the URI path hierarchy until the response includes a <code>Link</code> header field with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code>.</p>

                  <p about="" id="client-rdf-storage" rel="spec:requirement" resource="#client-rdf-storage"><a class="self-link" href="#client-rdf-storage"></a>Clients can discover a storage by making an HTTP <code>GET</code> request on the target URL to retrieve an RDF representation [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>], whose encoded RDF graph contains a relation of type <code>http://www.w3.org/ns/pim/space#storage</code>. The object of the relation is the storage (<code>pim:Storage</code>).</p>

                  <p>[<a href="https://github.com/solid/data-interoperability-panel/issues/10#issuecomment-598694029" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/153#issuecomment-624630022" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p about="" id="server-storage-description" rel="spec:requirement" resource="#server-storage-description"><a class="self-link" href="#server-storage-description"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include the <code>Link</code> header field with <code>rel="http://www.w3.org/ns/solid/terms#storageDescription"</code> targeting the URI of the storage description resource in the response of HTTP <code>GET</code>, <code>HEAD</code> and <code>OPTIONS</code> requests targeting a resource in a storage.</span></p>

                  <p about="" id="server-storage-description-resource" rel="spec:requirement" resource="#server-storage-description-resource"><a class="self-link" href="#server-storage-description-resource"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include <a href="#storage-description-statements" rel="rdfs:seeAlso">statements about the storage</a> as part of the storage description resource.</span></p>

                  <p about="#storage-description-statements" id="storage-description-statements" typeof="skos:Collection"><a class="self-link" href="#storage-description-statements"></a><span property="skos:prefLabel">Storage description statements</span> include the properties:</p>

                  <dl about="#storage-description-statements" rel="skos:member">
                    <dt about="#storage-description-rdf-type" id="storage-description-rdf-type" property="skos:prefLabel" typeof="skos:Concept"><a class="self-link" href="#storage-description-rdf-type"></a><code>rdf:type</code></dt>
                    <dd about="#storage-description-rdf-type" property="skos:definition">A class whose URI is <code>http://www.w3.org/ns/pim/space#Storage</code>.</dd>
                  </dl>

                  <p>[<a href="https://github.com/solid/specification/issues/355" rel="cito:citesAsSourceDocument">Source</a>].</p>

                  <p about="" id="server-storage-track-owner" rel="spec:requirement" resource="#server-storage-track-owner"><a class="self-link" href="#server-storage-track-owner"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> keep track of at least one <a href="#owner">owner</a> of a storage in an implementation defined way.</span></p>

                  <p about="" id="server-storage-link-owner" rel="spec:requirement" resource="#server-storage-link-owner"><a class="self-link" href="#server-storage-link-owner"></a><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="#Server">server</span> wants to advertise the owner of a storage, the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include the <code>Link</code> header field with <code>rel="http://www.w3.org/ns/solid/terms#owner"</code> targeting the URI of the owner in the response of HTTP <code>HEAD</code> or <code>GET</code> requests targeting the root container.</span></p>

                  <p>[<a href="https://github.com/solid/specification/issues/67" rel="cito:citesAsSourceDocument">Source</a>][<a href=" https://github.com/solid/specification/issues/132" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/153" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/197" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>

              <section id="resource-containment" inlist="" rel="schema:hasPart" resource="#resource-containment"><a class="self-link" href="#resource-containment"></a>
                <h3 property="schema:name">Resource Containment</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>Solid has the notion of containers to represent a collection of linked resources to help with resource discovery and lifecycle management.</p>

                  <p id="server-hierarchical-containment"><a class="self-link" href="#server-hierarchical-containment"></a>There is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy. [<a href="https://github.com/solid/specification/issues/98#issuecomment-547506617" rel="cito:citesAsSourceDocument">Source</a>]. It follows that all resources are discoverable from a container and that it is not possible to create orphan resources. [<a href="https://github.com/solid/specification/issues/97#issuecomment-547459396" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p about="" id="server-basic-container" rel="spec:requirement" resource="#server-basic-container"><a class="self-link" href="#server-basic-container"></a><span property="spec:statement">The representation and behaviour of containers in Solid corresponds to LDP Basic Container and <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be supported by <span rel="spec:requirementSubject" resource="#Server">server</span>.</span> [<a href="https://github.com/solid/specification/issues/47#issuecomment-561675764" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p id="server-container-last-modified"><a class="self-link" href="#server-container-last-modified"></a>Servers can determine the field value of the HTTP <code>Last-Modified</code> header field in response to <code>HEAD</code> and <code>GET</code> requests targeting a container based on changes to containment triples.</p>

                  <div class="note" id="container-last-modified-comparison" inlist="" rel="schema:hasPart" resource="#container-last-modified-comparison"><a class="self-link" href="#container-last-modified-comparison"></a>
                    <h4 property="schema:name"><span>Note</span>: Container Last-Modified Comparison</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p about="" id="container-last-modified-reliability" rel="spec:advisement" resource="#container-last-modified-reliability"><a class="self-link" href="#container-last-modified-reliability"></a><span property="spec:statement">The <code>Last-Modified</code> of a container will not change when other parts of the container changes. This is to avoid instant propagation of changes all the way to the root container. As <code>Last-Modified</code> <span rel="spec:advisementLevel" resource="spec:Cannot">cannot</span> be reliably used to check whether the container representation has changed in any way, relying on it for change detection is not meaningful. In future versions of this specification, this design may be revisited.</span></p>
                    </div>
                  </div>

                  <section id="contained-resource-metadata" inlist="" rel="schema:hasPart" resource="#contained-resource-metadata"><a class="self-link" href="#contained-resource-metadata"></a>
                    <h4 property="schema:name">Contained Resource Metadata</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>Container descriptions are not limited to containment triples. To further support client navigation and application interaction, servers can include <a href="#resource-metadata">resource metadata</a> about contained resources as part of the container description, as described below.</p>

                      <p about="" id="server-contained-resource-metadata" rel="spec:requirement" resource="#server-contained-resource-metadata"><a class="self-link" href="#server-contained-resource-metadata"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> include <a href="#contained-resource-metadata-statements" rel="rdfs:seeAlso">resource metadata about contained resources</a> as part of the container description, unless that information is inapplicable to the server.</span></p>

                      <p about="#contained-resource-metadata-statements" id="contained-resource-metadata-statements" typeof="skos:Collection"><a class="self-link" href="#contained-resource-metadata-statements"></a><span property="skos:prefLabel">Contained resource metadata statements</span> include the properties:</p>

                      <dl about="#contained-resource-metadata-statements" rel="skos:member">
                        <dt about="#contained-resource-metadata-rdf-type" id="contained-resource-metadata-rdf-type" property="skos:prefLabel" typeof="skos:Concept"><a class="self-link" href="#contained-resource-metadata-rdf-type"></a><code>rdf:type</code></dt>
                        <dd about="#contained-resource-metadata-rdf-type" property="skos:definition">A class whose URI is the expansion of the <em>URI Template</em> [<cite><a class="bibref" href="#bib-rfc6570">RFC6570</a></cite>] <code>http://www.w3.org/ns/iana/media-types/{+iana-media-type}#Resource</code>, where <code>iana-media-type</code> corresponds to a value from the IANA Media Types [<cite><a class="bibref" href="#bib-iana-media-types">IANA-MEDIA-TYPES</a></cite>].</dd>
                        <dt about="#contained-resource-metadata-stat-size" id="contained-resource-metadata-stat-size" property="skos:prefLabel" typeof="skos:Concept"><a class="self-link" href="#contained-resource-metadata-stat-size"></a><code>stat:size</code></dt>
                        <dd about="#contained-resource-metadata-stat-size" property="skos:definition">A non-negative integer giving the size of the resource in bytes.</dd>
                        <dt about="#contained-resource-metadata-dcterms-modified" id="contained-resource-metadata-dcterms-modified" property="skos:prefLabel" typeof="skos:Concept"><a class="self-link" href="#contained-resource-metadata-dcterms-modified"></a><code>dcterms:modified</code></dt>
                        <dd about="#contained-resource-metadata-dcterms-modified" property="skos:definition">The date and time when the resource was last modified.</dd>
                        <dt about="#contained-resource-metadata-stat-mtime" id="contained-resource-metadata-stat-mtime" property="skos:prefLabel" typeof="skos:Concept"><a class="self-link" href="#contained-resource-metadata-stat-mtime"></a><code>stat:mtime</code></dt>
                        <dd about="#contained-resource-metadata-stat-mtime" property="skos:definition">The Unix time when the resource was last modified.</dd>
                      </dl>

                      <p id="dcterms-modified-corresponds-last-modified"><a class="self-link" href="#dcterms-modified-corresponds-last-modified"></a>The <code>dcterms:modified</code> value of a contained resource corresponds with the <code>Last-Modified</code> header field value of the contained resource. If one were to perform <code>HEAD</code> or <code>GET</code> requests on the URI of the contained resource at the time of the HTTP message’s generation, then a response with the <code>200</code> status code including the <code>Last-Modified</code> header field would indicate the same date and time.</p>

                      <div class="note" id="contained-resource-metadata-considerations" inlist="" rel="schema:hasPart" resource="#contained-resource-metadata-considerations"><a class="self-link" href="#contained-resource-metadata-considerations"></a>
                        <h5 property="schema:name"><span>Note</span>: Contained Resource Metadata Considerations</h5>
                        <div datatype="rdf:HTML" property="schema:description">
                          <p about="" id="contained-resource-metadata-inapplicable" rel="spec:advisement" resource="#contained-resource-metadata-inapplicable"><a class="self-link" href="#contained-resource-metadata-inapplicable"></a><span property="spec:statement">The generation of contained resource metadata <span rel="spec:advisementLevel" resource="spec:Might">might</span> be inapplicable to some servers, for example, when that information does not exist or is expensive to determine.</span></p>
                        </div>
                      </div>

                      <p>Contained resource metadata is <a href="#server-protect-contained-resource-metadata" rel="cito:discusses">protected by the server</a>.</p>

                      <p>[<a href="https://github.com/solid/specification/issues/227" rel="cito:citesAsSourceDocument">Source</a>]
                      [<a href="https://github.com/solid/specification/issues/343" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/352" rel="cito:citesAsSourceDocument">Source</a>]</p>
                    </div>
                  </section>
                </div>
              </section>

              <section id="auxiliary-resources" inlist="" rel="schema:hasPart" resource="#auxiliary-resources"><a class="self-link" href="#auxiliary-resources"></a>
                <h3 property="schema:name">Auxiliary Resources</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>Solid has the notion of <em>auxiliary resources</em> to provide supplementary information such as descriptive metadata, authorization conditions, data shape constraints, digital rights or provenance record about a given resource (hereafter referred as the <em>subject resource</em>), and affects how resources and others associated with it are processed, served or interpreted.</p>

                  <p about="" id="server-auxiliary-resources-management" rel="spec:requirement" resource="#server-auxiliary-resources-management"><a class="self-link" href="#server-auxiliary-resources-management"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> support auxiliary resources defined by this specification and manage the association between a subject resource and auxiliary resources.</span> When a subject resource is deleted its auxiliary resources are also deleted by the server (<a href="#server-delete-remove-auxiliary-resource">Server Deleting Auxiliary Resources</a>).</p>

                  <p id="auxiliary-resources-rdf-document"><a class="self-link" href="#auxiliary-resources-rdf-document"></a>Auxiliary resources are represented as <em>RDF document</em>s [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>]. HTTP interactions on auxiliary resources are subject to the requirements as per <cite><a href="#reading-writing-resources">Reading and Writing Resources</a></cite>.</p>

                  <div class="note" id="self-describing-resources" inlist="" rel="schema:hasPart" resource="#self-describing-resources"><a class="self-link" href="#self-describing-resources"></a>
                    <h4 property="schema:name"><span>Note</span>: Self-describing Resources</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p about="" id="self-describing-subject-resource" rel="spec:advisement" resource="#self-describing-subject-resource"><a class="self-link" href="#self-describing-subject-resource"></a><span property="spec:statement">Where applicable, to promote <a href="https://www.w3.org/2001/tag/doc/selfDescribingDocuments">self-describing resources</a>, implementations and authors are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to use the subject resource instead of the associated auxiliary resource.</span></p>
                    </div>
                  </div>

                  <div class="note" id="uri-origin" inlist="" rel="schema:hasPart" resource="#uri-origin"><a class="self-link" href="#uri-origin"></a>
                    <h4 property="schema:name"><span>Note</span>: URI Origin</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>The resource and the associated auxiliary resource can be on different origins [<cite><a class="bibref" href="#bib-rfc6454">RFC6454</a></cite>].</p>
                    </div>
                  </div>

                  <p>This specification defines the following types of auxiliary resources:</p>

                  <ul>
                    <li><a href="#auxiliary-resources-web-access-control">Web Access Control</a></li>
                    <li><a href="#auxiliary-resources-description-resource">Description Resource</a></li>
                  </ul>

                  <p about="" id="server-link-auxiliary-type" rel="spec:requirement" resource="#server-link-auxiliary-type"><a class="self-link" href="#server-link-auxiliary-type"></a><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> advertise auxiliary resources associated with a subject resource by responding to <code>HEAD</code> and <code>GET</code> requests by including the HTTP <code>Link</code> header field with the <code>rel</code> parameter [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>].</span></p>

                  <p about="" id="client-link-auxiliary-type" rel="spec:requirement" resource="#client-link-auxiliary-type"><a class="self-link" href="#client-link-auxiliary-type"></a>Clients can discover auxiliary resources associated with a subject resource by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking the HTTP <code>Link</code> header field with the <code>rel</code> parameter [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>].</p>