specification/protocol.html at 6339dd2f88e8d3eb20b14f57173c2c59de5d1e71 · 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" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Solid Protocol</title>
    <meta content="width=device-width, initial-scale=1" name="viewport" />
    <link href="https://www.w3.org/StyleSheets/TR/2016/W3C-ED" media="all" rel="stylesheet" title="W3C-ED" />
<style>
body {
counter-reset:section;
counter-reset:sub-section;
}
em.rfc2119 { color: #900; }
code { color: #c83500; }
pre code { color: #333; }
dfn { font-style: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;
padding: 1em 1.2em 0.5em;
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;
}
div.issue h3 > span, div.note h3 > span,
div.issue h4 > span, div.note h4 > span,
div.issue h5 > span, div.note h5 > span {
text-transform: uppercase;
}
div.issue h3, div.issue h4, div.issue h5 {
color:#ae1e1e;
}
div.note h3, div.note h4, div.note h5 {
color:#178217;
}
figure .example-h {
margin-top:0;
text-align: left;
text-transform: uppercase;
color:#827017;
}
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"] {
-moz-border-bottom-colors: none;
-moz-border-left-colors: none;
-moz-border-right-colors: none;
-moz-border-top-colors: none;
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;
}

article section:not([id=abstract]):not([id=sotd]):not([id=references]):not([id=appendix]):not([id=acknowledgements]):not([id=change-log]):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=change-log]) 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=change-log]) 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=change-log]) 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=change-log]):not([id="exit-criteria"]):not([id^=table-of-]) > h2:before {
content:counter(section) ".\00a0";
}
section:not([id$="references"]):not([id^=change-log]):not([id="exit-criteria"]) > h3:before {
content:counter(section) "." counter(sub-section) "\00a0";
}
section > h4:before {
content:counter(section)"." counter(sub-section) "." counter(sub-sub-section) "\00a0";
}

aside.note.do blockquote dl.published,
aside.note.do blockquote dl.license,
aside.note.do blockquote dl.rights {
top:-2em;
left:4.5em;
}

#acknowledgements ul { padding: 0; margin:0 }
#acknowledgements li { display:inline; }
#acknowledgements li:after { content: ", "; }
#acknowledgements li:last-child:after { content: ""; }

.dfn-panel {
    position: absolute;
    z-index: 35;
    height: auto;
    width: -webkit-fit-content;
    width: fit-content;
    max-width: 300px;
    max-height: 500px;
    overflow: auto;
    padding: 0.5em 0.75em;
    font: small Helvetica Neue, sans-serif, Droid Sans Fallback;
    background: #DDDDDD;
    color: black;
    border: outset 0.2em;
}
.dfn-panel:not(.on) { display: none; }
.dfn-panel * { margin: 0; padding: 0; text-indent: 0; }
.dfn-panel > b { display: block; }
.dfn-panel a { color: black; }
.dfn-panel a:not(:hover) { text-decoration: none !important; border-bottom: none !important; }
.dfn-panel > b + b { margin-top: 0.25em; }
.dfn-panel ul { padding: 0; }
.dfn-panel li { list-style: inside; }
.dfn-panel.activated {
    display: inline-block;
    position: fixed;
    left: .5em;
    bottom: 2em;
    margin: 0 auto;
    max-width: calc(100vw - 1.5em - .4em - .5em);
    max-height: 30vh;
}

.dfn-paneled { cursor: pointer; }
</style>
  </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# qb: http://purl.org/linked-data/cube# schema: http://schema.org/ doap: http://usefulinc.com/ns/doap# deo: http://purl.org/spar/deo/ fabio: http://purl.org/spar/fabio/ 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#" typeof="schema:CreativeWork prov:Entity as:Article">
    <header>
      <address>
        <a class="logo" href="https://solidproject.org/"><img height="66" width="72" alt="Solid Project" src="solid.svg"/></a>
      </address>
    </header>

    <main>
      <article about="" typeof="schema:Article doap:Specification">
        <h1 property="schema:name">Solid Protocol</h1>
        <h2>Editor’s Draft, 2021-11-05</h2>

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

        <div id="authors">
          <dl id="author-name">
            <dt>Editors</dt>
            <dd id="Sarven-Capadisli"><span about="" rel="schema:creator schema:editor schema:author"><span about="https://csarven.ca/#i" typeof="schema:Person"><a rel="schema:url" href="https://csarven.ca/"><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></dd>

            <dd id="Tim-Berners-Lee"><span about="" rel="schema:editor"><span about="https://www.w3.org/People/Berners-Lee/card#i" typeof="schema:Person"><a rel="schema:url" href="https://www.w3.org/People/Berners-Lee/"><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></dd>

            <dd id="Ruben-Verborgh"><span about="" rel="schema:editor schema:author"><span about="https://ruben.verborgh.org/profile/#me" typeof="schema:Person"><a rel="schema:url" href="https://ruben.verborgh.org/"><span about="https://ruben.verborgh.org/profile/#me" property="schema:name"><span property="schema:givenName">Ruben</span> <span property="schema:familyName">Verborgh</span></span></a></span></span></dd>

            <dd id="Kjetil-Kjernsmo"><span about="" rel="schema:editor"><span about="http://www.kjetil.kjernsmo.net/foaf#me" typeof="schema:Person"><a rel="schema:url" href="http://www.kjetil.kjernsmo.net/"><span about="http://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></dd>

            <dd id="Justin-Bingham"><span about="" rel="schema:editor"><span about="https://justin.bingham.id/#me" typeof="schema:Person"><a rel="schema:url" href="https://justin.bingham.id/"><span about="https://justin.bingham.id/#me" property="schema:name"><span property="schema:givenName">Justin</span> <span property="schema:familyName">Bingham</span></span></a></span></span></dd>

            <dd id="Dmitri-Zagidulin"><span about="" rel="schema:editor"><span about="http://computingjoy.com/" typeof="schema:Person"><a rel="schema:url" href="http://computingjoy.com/"><span about="http://computingjoy.com/" property="schema:name"><span property="schema:givenName">Dmitri</span> <span property="schema:familyName">Zagidulin</span></span></a></span></span></dd>
          </dl>
        </div>

        <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="2021-11-05T00:00:00Z" datatype="xsd:dateTime" datetime="2021-11-05T00:00:00Z" property="schema:dateModified">2021-11-05</time></dd>
        </dl>

        <dl id="document-repository">
          <dt>Repository</dt>
          <dd><a href="https://github.com/solid/specification" rel="doap:repository">GitHub</a></dd>
          <dd><a href="https://github.com/solid/specification/issues" rel="doap:bug-database">Issues</a></dd>
        </dl>

        <p class="copyright">MIT License. Copyright © 2019–2021 <a href="http://www.w3.org/community/solid/">W3C Solid Community Group</a>.</p>

        <div datatype="rdf:HTML" id="content" property="schema:description">
          <section id="abstract">
            <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">
            <h2 property="schema:name">Status of This Document</h2>
            <div property="schema:description" datatype="rdf:HTML">
              <p>This section describes the status of this document at the time of its publication.</p>

              <p>This document was published by the <a href="https://www.w3.org/community/solid/">Solid Community Group</a> as an Editor’s Draft. The sections that have been incorporated have been reviewed following the <a href="https://github.com/solid/process">Solid process</a>. However, the information in this document is still subject to change. You are invited to <a href="https://github.com/solid/specification/issues">contribute</a> any feedback, comments, or questions you might have.</p>

              <p>Publication as an Editor’s Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>

              <p>This document was produced by a group operating under the <a href="https://www.w3.org/community/about/agreements/cla/">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.</p>
            </div>
          </section>

          <nav id="toc">
            <h2 id="table-of-contents">Table of Contents</h2>
            <div>
              <ol class="toc">
                <li class="tocline">
                  <a class="tocxref" href="#abstract">Abstract</a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#sotd">Status of This Document</a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#introduction"><span class="secno">1</span> <span class="content">Introduction</span></a>
                  <ol>
                    <li><a href="#terminology"><span class="secno">1.1</span> <span class="content">Terminology</span></a></li>
                    <li><a href="#namespaces"><span class="secno">1.2</span> <span class="content">Namespaces</span></a></li>
                    <li><a href="#conformance"><span class="secno">1.3</span> <span class="content">Conformance</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#http"><span class="secno">2</span> <span class="content">Hypertext Transfer Protocol</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#uri"><span class="secno">3</span> <span class="content">Uniform Resource Identifier</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#resources"><span class="secno">4</span> <span class="content">Resources</span></a>
                  <ol>
                    <li><a href="#storage"><span class="secno">4.1</span> <span class="content">Storage</span></a></li>
                    <li><a href="#resource-containment"><span class="secno">4.2</span> <span class="content">Resource Containment</span></a></li>
                    <li><a href="#auxiliary-resources"><span class="secno">4.3</span> <span class="content">Auxiliary Resources</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#reading-writing-resources"><span class="secno">5</span> <span class="content">Reading and Writing Resources</span></a>
                  <ol>
                    <li><a href="#resource-type-heuristics"><span class="secno">5.1</span> <span class="content">Resource Type Heuristics</span></a></li>
                    <li><a href="#reading-resources"><span class="secno">5.2</span> <span class="content">Reading Resources</span></a></li>
                    <li><a href="#writing-resources"><span class="secno">5.3</span> <span class="content">Writing Resources</span></a></li>
                    <li><a href="#deleting-resources"><span class="secno">5.4</span> <span class="content">Deleting Resources</span></a></li>
                    <li><a href="#resource-representations"><span class="secno">5.5</span> <span class="content">Resource Representations</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#notifications"><span class="secno">6</span> <span class="content">Notifications</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#cors"><span class="secno">7</span> <span class="content">Cross-Origin Resource Sharing</span></a>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#identity"><span class="secno">8</span> <span class="content">Identity</span></a>
                  <ol>
                    <li><a href="#webid"><span class="secno">8.1</span> <span class="content">WebID</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#authentication"><span class="secno">9</span> <span class="content">Authentication</span></a>
                  <ol>
                    <li><a href="#solid-oidc"><span class="secno">9.1</span> <span class="content">Solid-OIDC</span></a></li>
                    <li><a href="#webid-tls"><span class="secno">9.2</span> <span class="content">WebID-TLS</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#authorization"><span class="secno">10</span> <span class="content">Authorization</span></a>
                  <ol>
                    <li><a href="#web-access-control"><span class="secno">10.1</span> <span class="content">Web Access Control</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#http-definitions"><span class="secno">11</span> <span class="content">HTTP Definitions</span></a>
                  <ol>
                    <li><a href="#http-headers"><span class="secno">11.1</span> <span class="content">HTTP Headers</span></a></li>
                    <li><a href="#link-relations"><span class="secno">11.2</span> <span class="content">Link Relations</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#considerations"><span class="secno">12</span> <span class="content">Considerations</span></a>
                  <ol>
                    <li><a href="#security-considerations"><span class="secno">12.1</span> <span class="content">Security Considerations</span></a></li>
                    <li><a href="#privacy-considerations"><span class="secno">12.2</span> <span class="content">Privacy Considerations</span></a></li>
                    <li><a href="#accessibility-considerations"><span class="secno">12.3</span> <span class="content">Accessibility Considerations</span></a></li>
                    <li><a href="#internationalization-considerations"><span class="secno">12.4</span> <span class="content">Internationalization Considerations</span></a></li>
                    <li><a href="#security-privacy-review"><span class="secno">12.5</span> <span class="content">Security and Privacy Review</span></a></li>
                  </ol>
                </li>
                <li class="tocline">
                  <a class="tocxref" href="#references"><span class="secno"></span> <span class="content">References</span></a>
                  <ol>
                    <li><a href="#normative-references"><span class="secno"></span> <span class="content">Normative References</span></a></li>
                    <li><a href="#informative-references"><span class="secno"></span> <span class="content">Informative References</span></a></li>
                  </ol>
                </li>
              </ol>
            </div>
          </nav>

          <section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction">
            <h2 about="#introduction" property="schema:name" typeof="deo:Introduction">Introduction</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>The aims of the Solid project are in line with those of the Web itself: empowerment towards <q cite="https://www.w3.org/2001/tag/doc/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/2001/tag/doc/ethical-web-principles/" rel="cito:citesForInformation">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 control policies, 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>. 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><a href="http://data.europa.eu/esco/occupation/a7c1d23d-aeca-4bee-9a08-5993ed98b135">Resource 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">
                <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="#data-pod"></span><span resource="#solid-app"></span><span resource="#uri"></span><span resource="#resource"></span><span resource="#container-resource"></span><span resource="#root-container"></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="#data-pod" property="skos:prefLabel" typeof="skos:Concept"><dfn id="data-pod">data pod</dfn></dt>
                    <dd about="#data-pod" property="skos:definition">A data pod is a place for storing documents, with mechanisms for controlling who can access what.</dd>

                    <dt about="#solid-app" property="skos:prefLabel" typeof="skos:Concept"><dfn id="solid-app">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="#data-pod">data pods</a>.</dd>

                    <dt about="#uri" property="skos:prefLabel" typeof="skos:Concept"><dfn id="uri">URI</dfn></dt>
                    <dd about="#uri" 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">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-rfc7231">RFC7231</a></cite>].</dd>

                    <dt about="#container-resource" property="skos:prefLabel" typeof="skos:Concept"><dfn id="container-resource">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">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="#agent" property="skos:prefLabel" typeof="skos:Concept"><dfn id="agent">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">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 data storage. An owner is identified by a URI, and implicitly has control over all data 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">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">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">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">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">
                <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>rdf</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>ldp</td>
                        <td>http://www.w3.org/ns/ldp#</td>
                        <td>[<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>]</td>
                      </tr>
                      <tr>
                        <td>solid</td>
                        <td>http://www.w3.org/ns/solid/terms#</td>
                        <td>Solid Terms</td>
                      </tr>
                      <tr>
                        <td>pim</td>
                        <td>http://www.w3.org/ns/pim/space#</td>
                        <td>Workspace Ontology</td>
                      </tr>
                      <tr>
                        <td>acl</td>
                        <td>http://www.w3.org/ns/auth/acl#</td>
                        <td>ACL Ontology</td>
                      </tr>
                    </tbody>
                  </table>
                </div>
              </section>

              <section id="conformance" inlist="" rel="schema:hasPart" resource="#conformance">
                <h3 property="schema:name">Conformance</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.</p>

                  <p>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in <a href="https://tools.ietf.org/html/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>
                </div>
              </section>
            </div>
          </section>

          <section id="http" inlist="" rel="schema:hasPart" resource="#http">
            <h2 property="schema:name">Hypertext Transfer Protocol</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>Solid clients and servers 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">
                <h3 property="schema:name">HTTP Server</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>A <span about="" id="server-http-11" rel="spec:requirement" resource="#server-http-11"><span property="spec:statement">data pod <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be an HTTP/1.1 <span rel="spec:requirementSubject" resource="spec:Server">server</span> [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>][<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span> <span about="" id="server-http-2" rel="spec:requirement" resource="#server-http-2"><span property="spec:statement">It <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> additionally be an HTTP/2  <span rel="spec:requirementSubject" resource="spec:Server">server</span> [<cite><a class="bibref" href="#bib-rfc7540">RFC7540</a></cite>]</span></span> to improve performance, especially in cases where individual clients are expected to send high numbers of successive requests.</p>

                  <p><span about="" id="server-tls-https" rel="spec:requirement" resource="#server-tls-https"><span property="spec:statement">A data pod <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 between clients and <span rel="spec:requirementSubject" resource="spec:Server">server</span>.</span></span> <span about="" id="server-tls-https-redirect" rel="spec:requirement" resource="#server-tls-https-redirect"><span property="spec:statement">When both <code>http</code> and <code>https</code> are supported, the <span rel="spec:requirementSubject" resource="spec: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.</span></span></p>

                  <p><span about="" id="server-conditional-requests" rel="spec:requirement" resource="#server-conditional-requests"><span property="spec:statement">A data pod <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> implement the <span rel="spec:requirementSubject" resource="spec:Server">server</span> part of <cite>HTTP/1.1 Conditional Requests</cite> [<cite><a class="bibref" href="#bib-rfc7232">RFC7232</a></cite>] to ensure that updates requested by clients will only be applied if given preconditions are met.</span></span> <span about="" id="server-caching" rel="spec:requirement" resource="#server-caching"><span property="spec:statement">It <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> additionally implement the <span rel="spec:requirementSubject" resource="spec:Server">server</span> part of <cite>HTTP/1.1 Caching</cite> [<cite><a class="bibref" href="#bib-rfc7234">RFC7234</a></cite>] to improve performance.</span></span> <span about="" id="server-range-requests" rel="spec:requirement" resource="#server-range-requests"><span property="spec:statement">A data pod <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> implement the <span rel="spec:requirementSubject" resource="spec:Server">server</span> part of <cite>HTTP/1.1 Range Requests</cite> [<cite><a class="bibref" href="#bib-rfc7233">RFC7233</a></cite>] to further improve performance for large representations.</span></span></p>

                  <p><span about="" id="server-authentication" rel="spec:requirement" resource="#server-authentication"><span property="spec:statement">A data pod <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> implement the <span rel="spec:requirementSubject" resource="spec:Server">server</span> part of <cite>HTTP/1.1 Authentication</cite> [<cite><a class="bibref" href="#bib-rfc7235">RFC7235</a></cite>].</span></span> <span about="" id="server-unauthenticated" rel="spec:requirement" resource="#server-unauthenticated"><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>), the <span rel="spec:requirementSubject" resource="spec:Server">server</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></span></p>

                  <p><span about="" id="server-content-type" rel="spec:requirement" resource="#server-content-type"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> reject <code>PUT</code>, <code>POST</code> and <code>PATCH</code> requests without the <code>Content-Type</code> header with a status code of <code>400</code>.</span></span> [<a href="https://github.com/solid/specification/issues/70#issuecomment-547924171" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>

              <section id="http-client" inlist="" rel="schema:hasPart" resource="#http-client">
                <h3 property="schema:name">HTTP Client</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><span about="" id="client-http-11" rel="spec:requirement" resource="#client-http-11"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="spec:Client">client</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be an HTTP/1.1 client [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>][<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span> <span about="" id="client-http-2" rel="spec:requirement" resource="#client-http-2"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> be an HTTP/2 client [<cite><a class="bibref" href="#bib-rfc7540">RFC7540</a></cite>] to improve performance.</span></span></p>

                  <p><span about="" id="client-conditional-requests" rel="spec:requirement" resource="#client-conditional-requests"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="spec:Client">client</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> implement the client parts of <cite>HTTP/1.1 Conditional Requests</cite> [<cite><a class="bibref" href="#bib-rfc7232">RFC7232</a></cite>] to only trigger updates when certain preconditions are met.</span></span> <span about="" id="client-caching" rel="spec:requirement" resource="#client-caching"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> implement <cite>HTTP/1.1 Caching</cite> [<cite><a class="bibref" href="#bib-rfc7234">RFC7234</a></cite>].</span></span> <span about="" id="client-range-requests" rel="spec:requirement" resource="#client-range-requests"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Clients</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> implement <cite>HTTP/1.1 Range Requests</cite> [<cite><a class="bibref" href="#bib-rfc7233">RFC7233</a></cite>] to improve performance.</span></span></p>

                  <p><span about="" id="client-authentication" rel="spec:requirement" resource="#client-authentication"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="spec:Client">client</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> implement the client part of <cite>HTTP/1.1 Authentication</cite> [<cite><a class="bibref" href="#bib-rfc7235">RFC7235</a></cite>] if it needs to access resources requiring authentication (see <a href="#webid">WebID</a>).</span></span> <span about="" id="client-authentication-different-credentials" rel="spec:requirement" resource="#client-authentication-different-credentials"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="spec: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></span></p>

                  <p><span about="" id="client-content-type" rel="spec:requirement" resource="#client-content-type"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="spec:Client">client</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> use the <code>Content-Type</code> HTTP header in <code>PUT</code>, <code>POST</code> and <code>PATCH</code> requests [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span> [<a href="https://github.com/solid/specification/issues/70#issuecomment-547924171" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>
            </div>
          </section>

          <section id="uri" inlist="" rel="schema:hasPart" resource="#uri">
            <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">
                <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 Solid 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">
                <h3 property="schema:name">URI Slash Semantics</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p id="uri-slashes-hierarchical-identifier">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"><span property="spec:statement">If two URIs differ only in the trailing slash, and the <span rel="spec:requirementSubject" resource="spec:Server">server</span> has associated a resource with one of them, then the other URI <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> NOT correspond to another resource.</span></span> <span about="" id="server-uri-redirect-differing" rel="spec:requirement" resource="#server-uri-redirect-differing"><span property="spec:statement">Instead, the <span rel="spec:requirementSubject" resource="spec: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"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec: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">
                <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">
                    <h4 property="schema:name"><span>Note</span>: URI Reuse</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>Servers that wish to disable URI re-use may want to use the <code>410</code> status code.</p>
                    </div>
                  </div>
                </div>
              </section>
            </div>
          </section>

          <section id="resources" inlist="" rel="schema:hasPart" resource="#resources">
            <h2 property="schema:name">Resources</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <section id="storage" inlist="" rel="schema:hasPart" resource="#storage">
                <h3 property="schema:name">Storage</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><span about="" id="server-storage" rel="spec:requirement" resource="#server-storage"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="spec:Server">server</span> supports a data pod, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> provide one or more storages (<code>pim:Storage</code>) – a space of URIs in which data can be accessed. A storage is the root container for all of its contained resources (see <a href="#resource-containment">Resource Containment</a>).</span></span></p>

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

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

                  <p><span about="" id="client-link-storage" rel="spec:requirement" resource="#client-link-storage">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 with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code>.</span></p>

                  <p><span about="" id="client-storage-disovery" rel="spec:requirement" resource="#client-storage-discovery">Clients can determine the storage of a resource by moving up the URI path hierarchy until the response includes a <code>Link</code> header with <code>rel="type"</code> targeting <code>http://www.w3.org/ns/pim/space#Storage</code>. Clients may check the root path of a URI for the storage claim at any time.</span></p>

                  <p><span about="" id="client-rdf-storage" rel="spec:requirement" resource="#client-rdf-storage">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>).</span></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><span about="" id="server-storage-track-owner" rel="spec:requirement" resource="#server-storage-track-owner"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec: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></span></p>

                  <p><span about="" id="server-storage-link-owner" rel="spec:requirement" resource="#server-storage-link-owner"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="spec: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 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></span></p>

                  <div class="note" id="trust-between-owners" inlist="" rel="schema:hasPart" resource="#trust-between-owners">
                    <h4 property="schema:name"><span>Note</span>: Trust Between Owners</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>When a server supports multiple storages, there must be complete trust between its owners.</p>
                    </div>
                  </div>

                  <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">
                <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">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><span about="" id="server-basic-container" rel="spec:requirement" resource="#server-basic-container"><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="spec:Server">server</span>.</span></span> [<a href="https://github.com/solid/specification/issues/47#issuecomment-561675764" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>

              <section id="auxiliary-resources" inlist="" rel="schema:hasPart" resource="#auxiliary-resources">
                <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 id="auxiliary-resources-management">Server manages the association between a subject resource and auxiliary resources defined by this specification. The lifecycle of auxiliary resources defined by this specification depend on the lifecycle of the subject resource that they are associated with.</p>

                  <p id="auxiliary-resources-rdf-document">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="" inlist="self-describing-resources" rel="schema:hasPart" resource="#self-describing-resources">
                    <h4 property="schema:name"><span>Note</span>: Self-describing Resources</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>Where applicable, to promote <a href="https://www.w3.org/2001/tag/doc/selfDescribingDocuments">self-describing resources</a>, implementations and authors are encouraged to use the subject resource instead of the associated auxiliary resource.</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">Resource Description</a></li>
                  </ul>

                  <p><span about="" id="client-link-auxiliary-type" rel="spec:requirement" resource="#client-link-auxiliary-type">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 with the <code>rel</code> parameter [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>].</span></p>

                  <table>
                    <thead>
                      <tr>
                        <th>Auxiliary Type</th>
                        <th>Link Relation</th>
                        <th>Definitions</th>
                      </tr>
                    </thead>
                    <tbody>
                      <tr>
                        <td><a href="#auxiliary-resources-web-access-control">Web Access Control</a></td>
                        <td><code>acl</code></td>
                        <td>[<cite><a href="#link-relation-acl">Solid Protocol</a></cite>]</td>
                      </tr>
                      <tr>
                        <td><a href="#auxiliary-resources-description-resource">Description Resource</a></td>
                        <td><code>describedby</code></td>
                        <td>[<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>]</td>
                      </tr>
                    </tbody>
                    <tfoot>
                      <tr>
                        <td colspan="3">
                          <div class="issue">
                            <p>The possibility of using URIs as relation types interchangeably or as alternate to the tokens above are under consideration:</p>

                            <ul>
                              <li><code>http://www.w3.org/ns/auth/acl#accessControl</code></li>
                              <li><code>https://www.w3.org/ns/iana/link-relations/relation#acl</code></li>
                              <li><code>https://www.w3.org/ns/iana/link-relations/relation#describedby</code></li>
                              <li><code>https://www.w3.org/ns/iana/link-relations/relation#describes</code></li>
                            </ul>

                            <p><a href="https://github.com/solid/specification/issues/172">Issue</a></p>
                          </div>
                        </td>
                      </tr>
                    </tfoot>
                  </table>

                  <section id="auxiliary-resources-web-access-control" inlist="" rel="schema:hasPart" resource="#auxiliary-resources-web-access-control">
                    <h4 property="schema:name">Web Access Control</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>An auxiliary resource of type <em>Web Access Control</em> provides access control description of a subject resource (<a href="#web-access-control">Web Access Control</a>).</p>
                    </div>
                  </section>

                  <section id="auxiliary-resources-description-resource" inlist="" rel="schema:hasPart" resource="#auxiliary-resources-description-resource">
                    <h4 property="schema:name">Description Resource</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>An auxiliary resource of type <em>Description Resource</em> provides a description of a subject resource ([<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>]).</p>

                      <p><span about="" id="server-description-resource-max" rel="spec:requirement" resource="#server-description-resource-max"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> NOT directly associate more than one description resource to a subject resource.</span></span></p>

                      <p><span about="" id="server-description-resource-authorization" rel="spec:requirement" resource="#server-description-resource-authorization"><span property="spec:statement">When an HTTP request targets a description resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> apply the authorization rule that is used for the subject resource with which the description resource is associated.</span></span></p>

                      <p><span about="" id="client-link-describes" rel="spec:requirement" resource="#client-link-describes">Clients can discover resources that are described by description resources by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking the HTTP <code>Link</code> header with a <code>rel</code> value of <code>describes</code> (inverse of the <code>describedby</code> relation) [<cite><a class="bibref" href="#bib-rfc6892">RFC6892</a></cite>].</span></p>
                    </div>
                  </section>
                </div>
              </section>
            </div>
          </section>

          <section id="reading-writing-resources" inlist="" rel="schema:hasPart" resource="#reading-writing-resources">
            <h2 property="schema:name">Reading and Writing Resources</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p><span about="" id="server-method-not-allowed" rel="spec:requirement" resource="#server-method-not-allowed"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>405</code> status code to requests using HTTP methods that are not supported by the target resource.</span></span> [<a href="https://github.com/solid/specification/issues/117" rel="cito:citesAsSourceDocument">Source</a>]</p>

              <section id="resource-type-heuristics" inlist="" rel="schema:hasPart" resource="#resource-type-heuristics">
                <h3 property="schema:name">Resource Type Heuristics</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>When creating new resources, servers can determine an effective request URI’s type by examining the URI path ending (<a href="#uri-slash-semantics">URI Slash Semantics</a>).</p>

                  <p><span about="" id="server-put-patch-uri-assignment" rel="spec:requirement" resource="#server-put-patch-uri-assignment"><span property="spec:statement">When a successful <code>PUT</code> or <code>PATCH</code> request creates a resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> use the effective request URI to assign the URI to that resource.</span></span></p>

                  <p><span about="" id="server-post-uri-assignment" rel="spec:requirement" resource="#server-post-uri-assignment"><span property="spec:statement">When a successful <code>POST</code> request creates a resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> assign a URI to that resource.</span></span> <span about="" id="server-slug-uri-assignment" rel="spec:requirement" resource="#server-slug-uri-assignment"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> allow clients to suggest the URI of a resource created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [<cite><a class="bibref" href="#bib-rfc5023">RFC5023</a></cite>].</span></span></p>

                  <div class="note" id="uri-allocation" inlist="" rel="schema:hasPart" resource="#uri-allocation">
                    <h4 property="schema:name"><span>Note</span>: URI Allocation</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>Clients can use <code>PUT</code> and <code>PATCH</code> requests to assign a URI to a resource. Clients can use <code>POST</code> requests to have the server assign a URI to a resource.</p>
                    </div>
                  </div>

                  <p>[<a href="https://github.com/solid/specification/pull/160#issuecomment-636822687" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/pull/263" rel="cito:citesAsSourceDocument">Source</a>].</p>
                </div>
              </section>

              <section id="reading-resources" inlist="" rel="schema:hasPart" resource="#reading-resources">
                <h3 property="schema:name">Reading Resources</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><span about="" id="server-safe-methods" rel="spec:requirement" resource="#server-safe-methods"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> support the HTTP <code>GET</code>, <code>HEAD</code> and <code>OPTIONS</code> methods [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>] for clients to read resources or to determine communication options.</span></span> [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p>When responding to authorized requests:</p>

                  <p><span about="" id="server-allow-methods" rel="spec:requirement" resource="#server-allow-methods"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate their support for HTTP Methods by responding to HTTP <code>GET</code> and <code>HEAD</code> requests for the target resource with the HTTP Method tokens in the HTTP response header <code>Allow</code>.</span></span></p>

                  <p><span about="" id="server-accept-headers" rel="spec:requirement" resource="#server-accept-headers"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate supported media types in the HTTP <code>Accept-Patch</code> [<cite><a class="bibref" href="#bib-rfc5789">RFC5789</a></cite>], <code>Accept-Post</code> [<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>] and <code>Accept-Put</code> [<cite><a href="#accept-put">The Accept-Put Response Header</a></cite>] response headers that correspond to acceptable HTTP methods listed in <code>Allow</code> header value in response to HTTP <code>GET</code> and <code>HEAD</code> requests.</span></span></p>

                  <p><span about="" id="server-options-asterisk-accept-headers" rel="spec:requirement" resource="#server-options-asterisk-accept-headers"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> include the HTTP <code>Accept-Patch</code>, <code>Accept-Post</code> and <code>Accept-Put</code> headers in the response of a <code>OPTIONS *</code> request.</span></span></p>

                  <p>[<a href="https://github.com/solid/specification/issues/85#issuecomment-575386251" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/43" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>

              <section id="writing-resources" inlist="" rel="schema:hasPart" resource="#writing-resources">
                <h3 property="schema:name">Writing Resources</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>Servers MUST support the HTTP <code>PUT</code>, <code>POST</code> and <code>PATCH</code> methods [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/304" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-put-patch-intermediate-containers" rel="spec:requirement" resource="#server-put-patch-intermediate-containers"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of <code>PUT</code> and <code>PATCH</code> requests.</span></span> [<a href="https://github.com/solid/specification/issues/68#issuecomment-561690124" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-post-container" rel="spec:requirement" resource="#server-post-container"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> allow creating new resources with a <code>POST</code> request to URI path ending <code>/</code>.</span></span> <span about="" id="server-post-container-create-resource" rel="spec:requirement" resource="#server-post-container-create-resource"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create a resource with URI path ending <code>/{id}</code> in container <code>/</code>.</span></span> <span about="" id="server-post-container-create-container" rel="spec:requirement" resource="#server-post-container-create-container"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create a container with URI path ending <code>/{id}/</code> in container <code>/</code> for requests including the HTTP <code>Link</code> header with <code>rel="type"</code> targeting a valid LDP container type.</span></span> [<a href="https://github.com/solid/specification/pull/160#issuecomment-636822687" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/190" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-post-target-not-found" rel="spec:requirement" resource="#server-post-target-not-found"><span property="spec:statement">When a <code>POST</code> method request targets a resource without an existing representation, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>404</code> status code.</span></span> [<a href="https://github.com/solid/specification/issues/108#issuecomment-549448159" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-put-patch-auxiliary-resource" rel="spec:requirement" resource="#server-put-patch-auxiliary-resource"><span property="spec:statement">When a <code>PUT</code> or <code>PATCH</code> method request targets an auxiliary resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create or update it.</span></span> <span about="" id="server-post-slug-auxiliary-resource" rel="spec:requirement" resource="#server-post-slug-auxiliary-resource"><span property="spec:statement">When a <code>POST</code> method request with the <code>Slug</code> header targets an auxiliary resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>403</code> status code and response body describing the error.</span></span> [<a href="https://github.com/solid/specification/issues/42#issuecomment-616688848" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-protect-containment" rel="spec:requirement" resource="#server-protect-containment"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> NOT allow HTTP <code>POST</code>, <code>PUT</code> and <code>PATCH</code> to update a container’s containment triples; if the server receives such a request, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid/specification/issues/40#issuecomment-573358652" rel="cito:citesAsSourceDocument">Source</a>]</p>

		  <p>
		    <span about="" id="server-patch-not-other" rel="spec:requirement" resource="#server-patch-not-other"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST-NOT">MUST NOT</span> allow a client to explicitly request multi-resource changes via the <code>PATCH</code> method, but the server is permitted to propagate side-effects of a change to the target resource to other resources.</span></span> [<a href="https://github.com/solid/specification/issues/125#issuecomment-873035679" rel="cito:citesAsSourceDocument">Source</a>]
		    <span about="" id="server-patch-not-other-response" rel="spec:requirement" resource="#server-patch-not-other-response"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> respond with a <code>422</code> status code [<cite><a class="bibref" href="#bib-rfc4918">RFC4918</a></cite>] and a message body that explains the error if it determines that such an instruction is attempted.</span></span>
		  </p>

                  <div class="note" id="conditional-update" inlist="" rel="schema:hasPart" resource="#conditional-update">
                    <h4 property="schema:name"><span>Note</span>: Conditional Update</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>Clients are encouraged to use the HTTP <code>If-None-Match</code> header with a value of <code>"*"</code> to prevent an unsafe request method (e.g., <code>PUT</code>, <code>PATCH</code>) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation. [<a href="https://github.com/solid/specification/issues/108#issuecomment-567272797" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/40#issuecomment-566995240" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/292" rel="cito:citesAsSourceDocument">Source</a>]</p>
                    </div>
                  </div>

                  <p><span about="" id="server-etag" rel="spec:requirement" resource="#server-etag"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> use the HTTP <code>ETag</code> header with a strong validator for RDF bearing representations in order to encourage clients to opt-in to using the <code>If-Match</code> header in their requests.</span></span></p>
                </div>
              </section>

              <section id="deleting-resources" inlist="" rel="schema:hasPart" resource="#deleting-resources">
                <h3 property="schema:name">Deleting Resources</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>Servers MUST support the HTTP <code>DELETE</code> method [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/304" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-delete-protect-root-container" rel="spec:requirement" resource="#server-delete-protect-root-container"><span property="spec:statement">When a <code>DELETE</code> request targets storage’s root container or its associated ACL resource, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>405</code> status code.</span></span> <span about="" id="server-disallow-delete" rel="spec:requirement" resource="#server-disallow-delete"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> exclude the <code>DELETE</code> method in the HTTP response header <code>Allow</code> in response to requests [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span> [<a href="https://github.com/solid/specification/issues/37#issuecomment-627281466" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-delete-remove-containment" rel="spec:requirement" resource="#server-delete-remove-containment"><span property="spec:statement">When a contained resource is deleted, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> also remove the corresponding containment triple, which has the effect of removing the deleted resource from the containing container.</span></span> [<a href="https://www.w3.org/TR/ldp#ldpc-del-contremovesconttriple" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-delete-remove-auxilary-resource" rel="spec:requirement" resource="#server-delete-remove-auxiliary-resource"><span property="spec:statement">When a contained resource is deleted, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> also delete the associated auxiliary resources (see the <a href="#auxiliary-resources">Auxiliary Resources</a> section).</span></span></p>

                  <p><span about="" id="server-delete-remove-empty-container" rel="spec:requirement" resource="#server-delete-remove-empty-container"><span property="spec:statement">When a <code>DELETE</code> request is made to a container, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> delete the container if it contains no resources.</span></span> <span about="" id="server-delete-protect-nonempty-container" rel="spec:requirement" resource="#server-delete-protect-nonempty-container"><span property="spec:statement">If the container contains resources, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>409</code> status code and response body describing the error.</span></span> [<a href="https://github.com/solid/specification/pull/187/files/b7426e95a1613e08195a853a4d0a403b7030f494#r447130915" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><em>This section is non-normative.</em></p>

                  <p id="server-delete-side-effects">The server might perform additional actions, as described in the normative references like [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. For example, the server could remove membership triples referring to the deleted resource, perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time, and so on.</p>

                  <p id="server-delete-get">Subsequent <code>GET</code> requests to the deleted resource usually result in a <code>404</code> or <code>410</code> status code, although HTTP allows others. [<a href="https://github.com/solid/specification/issues/72" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/46" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p class="issue">Pertaining to events and loss of control mitigation: https://github.com/solid/specification/issues/41#issuecomment-534679278</p>
                </div>
              </section>

              <section id="resource-representations" inlist="" rel="schema:hasPart" resource="#resource-representations">
                <h3 property="schema:name">Resource Representations</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><span about="" id="server-representation-turtle-jsonld" rel="spec:requirement" resource="#server-representation-turtle-jsonld"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="spec:Server">server</span> creates a resource on HTTP <code>PUT</code>, <code>POST</code> or <code>PATCH</code> requests such that the request’s representation data encodes an <em>RDF document</em> [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>] (as determined by the <code>Content-Type</code> header), the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> accept <code>GET</code> requests on this resource when the value of the <code>Accept</code> header requests a representation in <code>text/turtle</code> or <code>application/ld+json</code> [<cite><a class="bibref" href="#bib-turtle">Turtle</a></cite>] [<cite><a class="bibref" href="#bib-json-ld11">JSON-LD11</a></cite>].</span></span> [<a href="https://github.com/solid/specification/issues/45" rel="cito:citesAsSourceDocument">Source</a>] <a href="https://github.com/solid/specification/issues/69" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/109" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/195" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-representation-write-redirect" rel="spec:requirement" resource="#server-representation-write-redirect"><span property="spec:statement">When a <code>PUT</code>, <code>POST</code>, <code>PATCH</code> or <code>DELETE</code> method request targets a representation URL that is different than the resource URL, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>307</code> or <code>308</code> status code and <code>Location</code> header specifying the preferred URI reference.</span></span> [<a href="https://github.com/solid/specification/issues/109" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>
            </div>
          </section>

          <section id="notifications" inlist="" rel="schema:hasPart" resource="#notifications">
            <h2 property="schema:name">Notifications</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p><span about="" id="server-ldn" rel="spec:requirement" resource="#server-ldn"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</span></span></p>

              <p><span about="" id="client-ldn" rel="spec:requirement" resource="#client-ldn"><span property="spec:statement">A Solid <span rel="spec:requirementSubject" resource="spec:Client">client</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource’s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</span></span></p>
            </div>
          </section>

          <section id="websockets" inlist="" rel="schema:hasPart" resource="#websockets">
            <h2 property="schema:name">WebSockets</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>For real-time communication between client and server about changes affecting a resource, Solid uses the WebSocket API [<cite><a class="bibref" href="#bib-w3c-html">W3C-HTML</a></cite>] and the WebSocket Protocol.</p>

              <section id="websockets-pub-sub" inlist="" rel="schema:hasPart" resource="#websockets-pub-sub">
                <h3 property="schema:name">WebSockets Pub-Sub</h3>
                <div datatype="rdf:HTML" property="schema:description">
                </div>
              </section>

              <section id="websockets-patching" inlist="" rel="schema:hasPart" resource="#websockets-patching">
                <h3 property="schema:name">WebSockets Patching</h3>
                <div datatype="rdf:HTML" property="schema:description">
                </div>
              </section>
            </div>
          </section>

          <section id="cors" inlist="" rel="schema:hasPart" resource="#cors">
            <h2 property="schema:name">Cross-Origin Resource Sharing</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p><a href="#solid-app">Solid apps</a> typically access data from multiple sources. However, Web browsers by default prevent apps that run on one origin from accessing data on other origins. This cross-origin protection is a security mechanism that ensures malicious websites cannot simply read your profile or banking details from other websites. However, this reasonable default poses a problem even for benevolent Solid apps, which might have good reasons to access data from different places. For instance, a Solid app at <code>https://app.example/</code> would be prevented from accessing data on <code>https://guinan.example/</code> or <code>https://darmok.example/</code>, even when Guinan and Darmok have given the user of the app their permission to see some of their data.</p>

              <p>For cases where the other origins have their own access protection mechanism — <a href="#authorization">like within Solid</a> — the browser’s built-in cross-origin protection is actually an obstacle rather than a feature. After all, data pods already ensure through access control that certain documents can only be accessed by specific people or applications. Preventively blocking apps from different origins thus introduces an unnecessary barrier.</p>

              <p>Fortunately, Web servers can indicate to the browser that certain documents do not require cross-origin protection. This mechanism to selectively disable that protection is called <em>Cross-Origin Resource Sharing</em> or <em>CORS</em> [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>]. By responding to browser requests with a specific combination of HTTP headers, servers can indicate which actions are allowed for a given resource. For a Solid data pod, the goal is to allow <em>all</em> actions on the CORS level, such that the deeper <a href="#authorization">Authorization</a> layer can exert full control over the app’s allowed permissions. The next section describes how to achieve this through the right HTTP header configuration.</p>

              <section id="cors-server" inlist="" rel="schema:hasPart" resource="#cors-server">
                <h3 property="schema:name">CORS Server</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><span about="" id="server-cors" rel="spec:requirement" resource="#server-cors"><span property="spec:statement">A <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> implement the CORS protocol [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>] such that, to the extent possible, the browser allows Solid apps to send any request and combination of request headers to the data pod, and the Solid app can read any response and response headers received from the data pod. If the data pod wishes to block access to a resource, this MUST NOT happen via CORS but MUST instead be communicated to the Solid app in the browser through HTTP status codes such as <code>401</code>, <code>403</code>, or <code>404</code> [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</span></span></p>

                  <div class="note" id="cors-protocol-blocking" inlist="" rel="schema:hasPart" resource="#cors-protocol-blocking">
                    <h4 property="schema:name"><span>Note</span>: CORS Protocol Blocking</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>Since the CORS protocol is part of a Living Standard, it might be changed at any point, which might necessitate changes to data pod implementations for continued prevention of undesired blocking. A <a href="https://github.com/whatwg/fetch/issues/878">proposal</a> to mitigate this has been suggested.</p>
                    </div>
                  </div>

                  <p>Concretely, <span about="" id="server-cors-access-control-headers" rel="spec:requirement" resource="#server-cors-access-control-headers"><span property="spec:statement">whenever a <span rel="spec:requirementSubject" resource="spec:Server">server</span> receives an HTTP request containing a valid <code>Origin</code> header [<cite><a class="bibref" href="#bib-rfc6454">RFC6454</a></cite>], the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the appropriate <code>Access-Control-*</code> headers as specified in the CORS protocol [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>].</span></span> In particular, <span about="" id="server-cors-acao-vary" rel="spec:requirement" resource="#server-cors-acao-vary"><span property="spec:statement">the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> set the <code>Access-Control-Allow-Origin</code> header to the valid <code>Origin</code> value from the request and list <code>Origin</code> in the <code>Vary</code> header value.</span></span> <span about="" id="server-cors-aceh" rel="spec:requirement" resource="#server-cors-aceh"><span property="spec:statement">The <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> make all used response headers readable for the Solid app through <code>Access-Control-Expose-Headers</code> (with the possible exception of the <code>Access-Control-*</code> headers themselves).</span></span> <span about="" id="server-cors-options" rel="spec:requirement" resource="#server-cors-options"><span property="spec:statement">A <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> also support the HTTP <code>OPTIONS</code> method [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>] such that it can respond appropriately to CORS preflight requests.</span></span></p>

                  <p>Careful attention is warranted, especially because of the many edge cases. For instance, <span about="" id="server-cors-enumerate" rel="spec:requirement" resource="#server-cors-enumerate"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> explicitly enumerate all used response headers under <code>Access-Control-Expose-Headers</code> rather than resorting to <code>*</code>, which does not cover all cases (such as credentials mode set to <code>include</code>).</span></span> <span about="" id="server-cors-accept-acah" rel="spec:requirement" resource="#server-cors-accept-acah"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:SHOULD">SHOULD</span> also explicitly list <code>Accept</code> under <code>Access-Control-Allow-Headers</code></span></span>, because values longer than 128 characters (not uncommon for RDF-based Solid apps) would otherwise be blocked, despite shorter <code>Accept</code> headers being allowed without explicit mention.</p>
                </div>
              </section>
            </div>
          </section>

          <section id="identity" inlist="" rel="schema:hasPart" resource="#identity">
            <h2 property="schema:name">Identity</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <section id="webid" inlist="" rel="schema:hasPart" resource="#webid">
                <h3 property="schema:name">WebID</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>A <em>WebID</em> is an HTTP URI denoting an agent, for example a person, organisation, or software [<cite><a class="bibref" href="#bib-webid">WEBID</a></cite>]. When a WebID is dereferenced, server provides a representation of the WebID Profile in an <em>RDF document</em> [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>] which uniquely describes an agent denoted by a WebID. WebIDs are an underpinning component in the Solid ecosystem and are used as the primary identifier for users and applications.</p>
                </div>
              </section>
            </div>
          </section>

          <section id="authentication" inlist="" rel="schema:hasPart" resource="#authentication">
            <h2 property="schema:name">Authentication</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <section id="solid-oidc" inlist="" rel="schema:hasPart" resource="#solid-oidc">
                <h3 property="schema:name">Solid-OIDC</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>The Solid OpenID Connect (Solid OIDC) specification defines how resource servers verify the identity of relying parties and end users based on the authentication performed by an OpenID provider [<cite><a class="bibref" href="#bib-solid-oidc">SOLID-OIDC</a></cite>].</p>
                </div>
              </section>

              <section id="webid-tls" inlist="" rel="schema:hasPart" resource="#webid-tls">
                <h3 property="schema:name">WebID-TLS</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>

                  <p>The Solid ecosystem initially relied on WebID-TLS for authenticated resource access <a class="bibref" href="#bib-webid-tls">[WEBID-TLS]</a>. The current recommendation for authentication relies on Solid-OIDC (<a href="#solid-oidc">Solid-OIDC</a>). Implementations can use WebID-TLS just as any other mechanism as an additional authentication method.</p>
                </div>
              </section>
            </div>
          </section>


          <section id="authorization" inlist="" rel="schema:hasPart" resource="#authorization">
            <h2 property="schema:name">Authorization</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <section id="web-access-control" inlist="" rel="schema:hasPart" resource="#web-access-control">
                <h3 property="schema:name">Web Access Control</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>Web Access Control (<abbr title="Web Access Control">WAC</abbr>) is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization conditions on HTTP resources using the Access Control List (<abbr title="Access Control List">ACL</abbr>) model. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the <cite><a href="http://www.w3.org/ns/auth/acl" rel="cito:citesAsAuthority">ACL ontology</a></cite> to express and determine access privileges of a requested resource. Applications can discover authorization rules associated with a given resource, and to control such rules, as directed by an agent.</p>

                  <p><span about="" id="server-wac" rel="spec:requirement" resource="#server-wac"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> conform to the Web Access Control specification [<cite><a class="bibref" href="#bib-wac">WAC</a></cite>].</span></span></p>

                  <p><span about="" id="server-link-acl" rel="spec:requirement" resource="#server-link-acl"><span property="spec:statement">When a server wants to enable applications to discover the authorization rules associated with a given <a href="#resource">resource</a>, the <span rel="spec:requirementSubject" resource="spec:Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> advertise the <a href="#acl-resource">ACL resource</a> that is associated with a resource by responding to an HTTP request including a <code>Link</code> header with the <code>rel</code> value of <code>acl</code> (<cite><a href="#link-relation-acl" rel="rdfs:seeAlso">acl Link Relation</a></cite>) and the ACL resource as link target [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>].</span></span> [<a href="https://github.com/solid/specification/issues/31#issuecomment-548360553" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-inapplicable-acl" rel="spec:requirement" resource="#server-inapplicable-acl"><span property="spec:statement">In the event that a <span rel="spec:requirementSubject" resource="spec:Server">server</span> can’t apply an ACL to a resource, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> deny access.</span></span> [<a href="https://github.com/solid/specification/issues/130#issue-532777017" rel="cito:citesAsSourceDocument">Source</a>]</p>

                  <p><span about="" id="server-wac-allow" rel="spec:requirement" resource="#server-wac-allow"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> exposing client’s access privileges on a resource URL <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> advertise by including the <code>WAC-Allow</code> HTTP header in the response of HTTP <code>HEAD</code> and <code>GET</code> requests.</span></span></p>

                  <p>The syntax for the <code>WAC-Allow</code> header, using the ABNF syntax defined in Section 1.2 of [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>], is:</p>

                  <pre class="def">wac-allow        = "WAC-Allow" ":" OWS #access-param OWS
access-param     = permission-group OWS "=" OWS access-modes
permission-group = 1*ALPHA
access-modes     = DQUOTE OWS *1(access-mode *(RWS access-mode)) OWS DQUOTE
access-mode      = "read" / "write" / "append" / "control"</pre>

                  <p>The <code>WAC-Allow</code> HTTP header’s field-value is a comma-separated list of <code>access-param</code>s. <code>access-param</code> is a whitespace-separated list of <code>access-modes</code> granted to a <code>permission-group</code>.</p>

                  <p>This specification defines the following <code>permission-group</code>s:</p>

                  <dl>
                    <dt><code>user</code></dt>
                    <dd>Permissions granted to the agent requesting the resource.</dd>
                    <dt><code>public</code></dt>
                    <dd>Permissions granted to the public.</dd>
                  </dl>

                  <p><code>access-mode</code> corresponds to the modes of access as defined in the ACL ontology (<code>acl:Read</code>, <code>acl:Write</code>, <code>acl:Append</code>, <code>acl:Control</code>).</p>

                  <p><span about="" id="client-wac-allow" rel="spec:requirement" resource="#client-wac-allow">Clients can discover access privileges on a resource by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking the <code>WAC-Allow</code> header value for access parameters listing the allowed access modes per permission group.</span></p>

                  <p><span about="" id="client-wac-allow-parsing" rel="spec:requirement" resource="#client-wac-allow-parsing"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Client">Client</span> parsing algorithms for <code>WAC-Allow</code> header field-values <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received <code>WAC-Allow</code> header-field. When unrecognised access parameters (such as permission groups or access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.</span></span></p>

                  <p>[<a href="https://github.com/solid/specification/issues/171" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/170" rel="cito:citesAsSourceDocument">Source</a>] <a href="https://github.com/solid/specification/issues/181" rel="cito:citesAsSourceDocument">Source</a>] <a href="https://gitter.im/solid/specification?at=60101295d8bdab47395e6775" rel="cito:citesAsSourceDocument">Source</a>]</p>
                </div>
              </section>
            </div>
          </section>

          <section id="http-definitions" inlist="" rel="schema:hasPart" resource="#http-definitions">
            <h2 property="schema:name">HTTP Definitions</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <section id="http-headers" inlist="" rel="schema:hasPart" resource="#http-headers">
                <h3 property="schema:name">HTTP Headers</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <section id="accept-put" inlist="" rel="schema:hasPart" resource="#accept-put">
                    <h4 property="schema:name">The Accept-Put Response Header</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>This specification introduces a new HTTP response header <code>Accept-Put</code> used to specify the document formats accepted by the server on HTTP PUT requests. It is modelled after the <code>Accept-Patch</code> header defined in [<cite><a class="bibref" href="#bib-rfc5789">RFC5789</a></cite>] and the <code>Accept-Post</code> header defined in [<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>].</p>

                      <p>The syntax for <code>Accept-Put</code>, using the ABNF syntax defined in Section 1.2 of [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>], is:</p>

                      <pre class="def">Accept-Put = "Accept-Put" ":" # media-range</pre>

                      <p>The <code>Accept-Put</code> header specifies a comma-separated list of media ranges (with optional parameters) as defined by [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>], Section 5.3.2. The <code>Accept-Put</code> header, in effect, uses the same syntax as the HTTP <code>Accept</code> header minus the optional <code>accept-params</code> BNF production, since the latter does not apply to <code>Accept-Put</code>.</p>

                      <p>The presence of the <code>Accept-Put</code> header in response to any method is an implicit indication that <code>PUT</code> is allowed on the resource identified by the request URI. The presence of a specific document format in this header indicates that that specific format is allowed on <code>PUT</code> requests to the resource identified by the request URI.</p>

                      <p><strong>IANA Registration Template:</strong></p>

                      <p>The <code>Accept-Put</code> response header must be added to the permanent registry (see [<cite><a class="bibref" href="#bib-rfc3864">RFC3864</a></cite>]).</p>

                     <dl>
                      <dt>Header field name</dt>
                      <dd>Accept-Put</dd>
                      <dt>Applicable Protocol</dt>
                      <dd>HTTP</dd>
                      <dt>Author/Change controller</dt>
                      <dd>W3C Solid Community Group</dd>
                      <dt>Specification document</dt>
                      <dd>This specification</dd>
                     </dl>
                    </div>
                  </section>
                </div>
              </section>

              <section id="link-relations" inlist="" rel="schema:hasPart" resource="#link-relations">
                <h3 property="schema:name">Link Relations</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p>The intent is that these link relations will be registered with IANA per [<cite><a class="bibref" href="#bib-rfc8288">RFC8288</a></cite>].</p>

                  <section id="link-relation-acl" inlist="" rel="schema:hasPart" resource="#link-relation-acl">
                    <h4 property="schema:name">acl</h4>
                    <div datatype="rdf:HTML" property="schema:description">
                      <p>The contents of this section were originally taken from <a href="https://www.w3.org/wiki/WebAccessControl">Web Access Control</a>.</p>

                      <p>The following Link Relationship will be submitted to IANA for review, approval, and inclusion in the IANA Link Relations registry.</p>

                      <dl>
                        <dt>Relation Name</dt>
                        <dd><code>acl</code></dd>
                        <dt>Description</dt>
                        <dd>The relationship <code>A acl B</code> asserts that resource B provides access control description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.</dd>
                        <dt>Reference</dt>
                        <dd>This specification.</dd>
                        <dt>Notes</dt>
                        <dd>Consumers of ACL resources should be aware of the source and chain of custody of the data.</dd>
                      </dl>

                      <p>[<a href="https://github.com/solid/specification/issues/54" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/web-access-control-spec/issues/21" rel="cito:citesAsSourceDocument">Source</a>]</p>
                    </div>
                  </section>
                 </div>
              </section>
            </div>
          </section>

          <section id="considerations" inlist="" rel="schema:hasPart" resource="#considerations">
            <h2 property="schema:name">Considerations</h2>
            <div datatype="rdf:HTML" property="schema:description">
              <p>This section details security, privacy, accessibility and internationalization considerations.</p>

              <p>Some of the normative references with this specification point to documents with a <em>Living Standard</em> or <em>Draft</em> status, meaning their contents can still change over time. It is advised to monitor these documents, as such changes might have implications.</p>

              <section id="security-considerations" inlist="" rel="schema:hasPart" resource="#security-considerations">
                <h3 property="schema:name">Security Considerations</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>

                  <p>While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.</p>

                  <p id="consider-uri-http">Implementations are subject to the same security considerations that are found in HTTP/1.1 [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>] and [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</p>

                  <p id="consider-request-validation">Servers are strongly discouraged from assuming that HTTP request headers’ field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to apply normalization and canonicalization algorithms where applicable. Servers are encouraged to take measures to mitigate potential timing attacks attempting to discover resource existence even if requesting agent has no access to the resource(s). Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.</p>

                  <p id="consider-client-assumptions">Servers are strongly discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar values in headers such as <code>User-Agent</code> or <code>Origin</code>. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.</p>

                  <p id="consider-cors-protections">Servers <a href="#cors-server">disable all cross-origin protections</a> in browsers because resource access is governed explicitly by the <a href="#authorization">Authorization</a> component. As such, servers cannot rely on browser-based cross-origin protection mechanisms for determining the authentication status or representation of a resource. In particular, servers are strongly encouraged to ignore HTTP cookies from untrusted origins. Additional security measures can be taken to prevent metadata in error responses from leaking. For instance, a malicious application could probe multiple servers to check whether the response status code is <code>401</code> or <code>403</code>, or could try to access an error page from an intranet server within the user agent’s private network to extract company names or other data. To mitigate this, when a request from an untrusted <code>Origin</code> arrives, the server may want to set the status code of error responses to <code>404</code> and/or anonymize or censor their contents.</p>

                  <p id="consider-tls-connections">Servers are encouraged to use TLS connections to protect the contents of requests and responses from eavesdropping and modification by third parties. Unsecured TCP connections without TLS may be used in testing environments or when the data pod is behind a reverse proxy that terminates a secure connection.</p>
                </div>
              </section>

              <section id="privacy-considerations" inlist="" rel="schema:hasPart" resource="#privacy-considerations">
                <h3 property="schema:name">Privacy Considerations</h3>
                <div datatype="rdf:HTML" property="schema:description">
                  <p><em>This section is non-normative.</em></p>

                  <p id="consider-authorization-resources">Servers are encouraged to use authorization techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.</p>