-
Notifications
You must be signed in to change notification settings - Fork 49
/
Copy pathprotocol.html
1143 lines (953 loc) · 96.9 KB
/
protocol.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta charset="utf-8" />
<title>The 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 h4, div.note h4 {
margin:0;
text-transform: uppercase;
font-weight:normal;
}
div.issue h4 {
color:#ae1e1e;
}
div.note h4 {
color:#22bb22;
}
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#" typeof="schema:CreativeWork prov:Entity as:Article">
<header>
<address>
<a class="logo" href="https://solidproject.org/"><img height="66" width="72" alt="W3C" src="solid.svg"/></a>
</address>
</header>
<main>
<article about="" typeof="schema:Article doap:Specification">
<h1 property="schema:name">The Solid Protocol</h1>
<h2>Editor’s Draft, 2021-03-23</h2>
<dl id="document-identifier">
<dt>This version</dt>
<dd><a href="https://solidproject.org/TR/protocol" rel="owl:sameAs doap:homepage">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: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:author"><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: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:author"><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:author"><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:author"><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-03-23T00:00:00Z" datatype="xsd:dateTime" datetime="2021-03-23T00:00:00Z" property="schema:dateModified">2021-03-23</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="#definitions"><span class="secno">1.1</span> <span class="content">Definitions</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/">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/">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>
<section id="definitions" inlist="" rel="schema:hasPart" resource="#definitions">
<h3 property="schema:name">Definitions</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>A <dfn class="dfn-paneled" data-dfn-type="dfn" id="data-pod">data pod</dfn> is a place for storing documents, with mechanisms for controlling who can access what.</p>
<p>A <dfn class="dfn-paneled" data-dfn-type="dfn" id="solid-app">Solid app</dfn> is an application that reads or writes data from one or more <a data-link-type="dfn" href="#data-pod" id="ref-for-data-pod">data pods</a>.</p>
<p>A <dfn data-dfn-type="dfn" id="read-operation">read operation</dfn> 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>]</p>
<p>A <dfn data-dfn-type="dfn" id="write-operation">write operation</dfn> 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>]</p>
<p>An <dfn data-dfn-type="dfn" id="append-operation">append operation</dfn> 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>]</p>
</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">Required Server-Side Implementation</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>A <a data-link-type="dfn" href="#data-pod" id="ref-for-data-pod①">data pod</a> MUST be an HTTP/1.1 server [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>][<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. It SHOULD additionally be an HTTP/2 server [<cite><a class="bibref" href="#bib-rfc7540">RFC7540</a></cite>] to improve performance, especially in cases where individual clients are expected to send high numbers of successive requests.</p>
<p>A data pod SHOULD use TLS connections through the <code>https</code> URI scheme in order to secure the communication between clients and servers. When both <code>http</code> and <code>https</code> are supported, all <code>http</code> URIs MUST redirect to their <code>https</code> counterparts using a response with a <code>301</code> status code and a <code>Location</code> header.</p>
<p>A data pod MUST implement the server 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. It SHOULD additionally implement the server part of <cite>HTTP/1.1 Caching</cite> [<cite><a class="bibref" href="#bib-rfc7234">RFC7234</a></cite>] to improve performance. A data pod MAY implement the server 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.</p>
<p>A data pod MUST implement the server part of <cite>HTTP/1.1 Authentication</cite> [<cite><a class="bibref" href="#bib-rfc7235">RFC7235</a></cite>]. When a client does not provide valid credentials when requesting a resource that requires it (see <a href="#webid">WebID</a>), the data pod MUST send a response with a <code>401</code> status code (unless <code>404</code> is preferred for security reasons).</p>
<p>A Solid server MUST 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>. [<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">Required Client-Side Implementation</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>A Solid client MUST 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>]. It MAY additionally be an HTTP/2 client [<cite><a class="bibref" href="#bib-rfc7540">RFC7540</a></cite>] to improve performance.</p>
<p>A Solid client MAY 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. It MAY implement <cite>HTTP/1.1 Caching</cite> [<cite><a class="bibref" href="#bib-rfc7234">RFC7234</a></cite>] and <cite>HTTP/1.1 Range Requests</cite> [<cite><a class="bibref" href="#bib-rfc7233">RFC7233</a></cite>] to improve performance.</p>
<p>A Solid client MUST 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>). When it receives a response with a <code>403</code> or <code>404</code> status code, it MAY repeat the request with different credentials.</p>
<p>A Solid client MUST 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>]. [<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">
<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>The slash 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>If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource. Instead, the server MAY respond to requests for the latter URI with a 301 redirect to the former. [<a href="https://github.com/solid/specification/issues/107#issuecomment-567482817" rel="cito:citesAsSourceDocument">Source</a>]. Behaviour pertaining to authorization MUST precede this optional redirect [<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">
<em>This section is non-normative.</em>
<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>
<p class="note" role="note"><span>Note:</span> Servers that wish to disable URI re-use may want to use the <code>410</code> status code.</p>
</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>When a server supports a data pod, it MUST 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>).</p>
<p>When a server supports multiple storages, the URIs MUST be allocated to non-overlapping space.</p>
<p>Servers exposing the storage resource MUST 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.</p>
<p>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>.</p>
<p>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.</p>
<p>Clients can discover a storage by making an HTTP <code>GET</code> request on the target URL to retrieve an RDF representation [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>], whose encoded RDF graph contains a relation of type <code>http://www.w3.org/ns/pim/space#storage</code>. The object of the relation is the storage (<code>pim:Storage</code>).</p>
<p>[<a href="https://github.com/solid/data-interoperability-panel/issues/10#issuecomment-598694029" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/issues/153#issuecomment-624630022" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>When using Web Access Control (<a href="#web-access-control">Web Access Control</a>):</p>
<p>The root container (<code>pim:Storage</code>) MUST have an ACL auxiliary resource directly associated to it. The associated ACL document MUST include an authorization policy with <code>acl:Control</code> access privilege.</p>
<p>[<a href="https://github.com/solid/specification/issues/197#issuecomment-699937520" 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>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>The representation and behaviour of containers in Solid corresponds to LDP Basic Container and MUST be supported. [<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 policies, 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>Auxiliary resources are represented as <em>RDF document</em>s [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>].</p>
<p class="note" role="note"><span>Note:</span> 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>
<p>Servers exposing auxiliary resources that are defined by this specification MUST have the same "origin" for both the resource and the associated auxiliary resource [<cite><a class="bibref" href="#bib-rfc6454">RFC6454</a></cite>].</p>
<p>As per <a href="#deleting-resources">Deleting Resources</a>, the lifecycle of auxiliary resources defined by this specification depend on the lifecycle of the subject resource.</p>
<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>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>].</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#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>
<p>Servers MUST NOT directly associate more than one ACL auxiliary resource to a subject resource.</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>Servers MUST NOT directly associate more than one description resource to a subject resource.</p>
<p>When an HTTP request targets a description resource, the server MUST apply the authorization policy that is used for the subject resource with which the description resource is associated.</p>
<p>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>].</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>Servers MUST respond with the <code>405</code> status code to requests using HTTP methods that are not supported by the target resource. [<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>Clients who want to assign a URI to a resource, MUST use <code>PUT</code> and <code>PATCH</code> requests.</p>
<p>Clients who want the server to assign a URI of a resource, MUST use the <code>POST</code> request. Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP <code>Slug</code> header as defined in [<cite><a class="bibref" href="#bib-rfc5023">RFC5023</a></cite>].</p>
<p>[<a href="https://github.com/solid/specification/pull/160#issuecomment-636822687" 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>Servers MUST 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. [<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>Servers MUST 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>.</p>
<p>Servers MUST 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.</p>
<p>Servers MAY 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.</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>When a server supports the HTTP <code>PUT</code>, <code>POST</code> and <code>PATCH</code> methods [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>] this specification imposes the following requirements: [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>Servers MUST 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. [<a href="https://github.com/solid/specification/issues/68#issuecomment-561690124" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>Servers MUST allow creating new resources with a <code>POST</code> request to URI path ending <code>/</code>. Servers MUST create a resource with URI path ending <code>/{id}</code> in container <code>/</code>. Servers MUST 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. Servers MUST handle subsequent requests to the newly created container’s URI as if it is a valid LDP container type by including the HTTP response’s <code>Link</code> header. [<a href="https://github.com/solid/specification/pull/160#issuecomment-636822687" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>When a <code>POST</code> method request targets a resource without an existing representation, the server <code>MUST</code> respond with the <code>404</code> status code. [<a href="https://github.com/solid/specification/issues/108#issuecomment-549448159" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>When a <code>PUT</code> or <code>PATCH</code> method request targets an auxiliary resource, the server MUST create or update it. When a <code>POST</code> method request with the <code>Slug</code> header targets an auxiliary resource, the server MUST respond with the <code>403</code> status code and response body describing the error. [<a href="https://github.com/solid/specification/issues/42#issuecomment-616688848" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>Servers MUST 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 MUST respond with a <code>409</code> status code. [<a href="https://github.com/solid/specification/issues/40#issuecomment-573358652" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>Clients MAY use the HTTP <code>If-None-Match</code> header with a value of <code>"*"</code> to prevent an unsafe request method (eg. <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>]</p>
<p>Servers MAY 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.</p>
<p>When using Web Access Control (<a href="#web-access-control">Web Access Control</a>):</p>
<p>To create or update an ACL resource (see <a href="#auxiliary-resources-web-access-control">Web Access Control</a>), an <code>acl:agent</code> MUST have <code>acl:Control</code> privileges per the ACL inheritance algorithm on the resource directly associated with it. [<a href="https://github.com/solid/specification/issues/42#issuecomment-616688848" rel="cito:citesAsSourceDocument">Source</a>]</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>When a server supports the HTTP <code>DELETE</code> method [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>] this specification imposes the following requirements: [<a href="https://github.com/solid/specification/issues/39#issuecomment-538017667" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>When a <code>DELETE</code> request targets storage’s root container or its associated ACL resource, the server MUST respond with the <code>405</code> status code. Server MUST 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>]. [<a href="https://github.com/solid/specification/issues/37#issuecomment-627281466" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>When a contained resource is deleted, the server MUST also remove the corresponding containment triple, which has the effect of removing the deleted resource from the containing container. [<a href="https://www.w3.org/TR/ldp#ldpc-del-contremovesconttriple" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>When a contained resource is deleted, the server MUST also delete the associated auxiliary resources (see the <a href="#auxiliary-resources">Auxiliary Resources</a> section).</p>
<p>When a <code>DELETE</code> request is made to a container, the server MUST delete the container if it contains no resources. If the container contains resources, the server MUST respond with the <code>409</code> status code and response body describing the error. [<a href="https://github.com/solid/specification/pull/187/files/b7426e95a1613e08195a853a4d0a403b7030f494#r447130915" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>When using Web Access Control (<a href="#web-access-control">Web Access Control</a>):</p>
<p>To delete a resource, an <code>acl:agent</code> MUST have <code>acl:Write</code> privilege per the ACL inheritance algorithm on the resource and the containing container. [<a href="https://github.com/solid/specification/issues/197" rel="cito:citesAsSourceDocument">Source</a>]</p> <p>To delete an ACL resource (see <a href="#auxiliary-resources-web-access-control">Web Access Control</a>), an <code>acl:agent</code> MUST have <code>acl:Control</code> privileges per the ACL inheritance algorithm on the resource directly associated with it. [<a href="https://github.com/solid/specification/issues/145" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p><em>This section is non-normative.</em></p>
<p>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>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>As deleted resources can be reinstated with the same URI, access controls on the reinstated resource can change per the ACL inheritance algorithm. [<a href="https://github.com/solid/specification/issues/145#issuecomment-618918284" 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>When a server 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 MUST 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>]. [<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>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 server MUST respond with a <code>307</code> or <code>308</code> status code and <code>Location</code> header specifying the preferred URI reference. [<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>A Solid server MUST 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>].</p>
<p>A Solid client MUST 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>].</p>
<section id="inbox-discovery-client-error" inlist="" rel="schema:hasPart" resource="#inbox-discovery-client-error">
<h3 property="schema:name">Inbox Discovery on Client Error</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>This section extends the LDN protocol to allow the discovery of the Inbox URL of a target resource on client errors (HTTP responses with <code>4xx</code> status codes) [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>][<cite><a class="bibref" href="#bib-ldn">LDN</a></cite>].</p>
<p>Servers who want to advertise the Inbox URL in an HTTP response with a <code>4xx</code> status code, <code>MUST</code> do one of the following:</p>
<ul>
<li>Include the <code>Link</code> header with a <code>rel</code> value of <code>http://www.w3.org/ns/ldp#inbox</code>.</li>
<li>Return 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/ldp#inbox</code>. The subject of that relation is the target resource and the object is the Inbox.</li>
</ul>
<p>Senders do the following to discover the Inbox URL in an HTTP response with a <code>4xx</code> status code:</p>
<ul>
<li>Use the <code>Link</code> header with a <code>rel</code> value of <code>http://www.w3.org/ns/ldp#inbox</code>.</li>
<li>Parse 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/ldp#inbox</code>. The subject of that relation is the target resource and the object is the Inbox.</li>
</ul>
<p>These may be carried out in either order, but if the first fails to result in an Inbox the second MUST be tried.</p>
<figure class="listing example" id="discovery-put-example-403" rel="schema:hasPart" resource="#discovery-turtle-example-webid">
<p class="example-h">Discovery example: Client error</p>
<pre about="#discovery-put-example-403" property="schema:description" typeof="fabio:Script"><code>PUT /article HTTP/1.1</code>
<code>Host: example.org</code>
<code>Content-Type: text/html;charset=utf-8</code>
<code></code>
<code>HTTP/1.1 403 Forbidden</code>
<code>Link: <http://example.org/inbox/> rel="http://www.w3.org/ns/ldp#inbox"</code></pre>
<figcaption>Discovering an Inbox in the response of a rejected request.</figcaption>
</figure>
</div>
</section>
</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 data-link-type="dfn" href="#solid-app" id="ref-for-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://alice-data-pod.example/</code> or <code>https://bob-data-pod.example/</code>, even when Alice and Bob 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—<wbr><a href="#web-access-control">like within Solid</a></wbr>— the browser’s built-in cross-origin protection is actually an obstacle rather than a feature. After all, <a data-link-type="dfn" href="#data-pod" id="ref-for-data-pod②">data pods</a> 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="#web-access-control">access control layer</a> 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">Required Server-Side Implementation</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>A <a data-link-type="dfn" href="#data-pod" id="ref-for-data-pod③">data pod</a> MUST 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>].</p>
<p class="note" role="note"><span>Note:</span> 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>
<p>Concretely, whenever a data pod receives an HTTP request containing a valid <code>Origin</code> header [<cite><a class="bibref" href="#bib-rfc6454">RFC6454</a></cite>], the server MUST 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>]. In particular, the data pod MUST 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. The data pod MUST 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). A data pod MUST 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.</p>
<p>Careful attention is warranted, especially because of the many edge cases. For instance, data pods SHOULD 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>). Data pods SHOULD also explicitly list <code>Accept</code> under <code>Access-Control-Allow-Headers</code>, 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 a 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>
<p>When using Web Access Control (<a href="#web-access-control">Web Access Control</a>):</p>
<p>Agents accessing non-public Solid resources need to authenticate with a WebID.</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. The WAC mechanism is concerned with giving access to agents denoted by a <a href="#webid">WebID</a> to perform various kinds of read-write operations on resources identified by URLs. The <cite><a href="http://www.w3.org/ns/auth/acl">Access Control List</a></cite> (<abbr title="Access Control List">ACL</abbr>) ontology is used to describe authorization policies about agents with modes of access on target resources.</p>
<p>Servers MUST conform to the Web Access Control specification [<cite><a class="bibref" href="#bib-wac">WAC</a></cite>].</p>
<p>A resource can advertise an ACL document that is directly associated by using the HTTP <code>Link</code> header with a <code>rel</code> value of <code>acl</code> <a href="#acl">acl</a>. [<a href="https://github.com/solid/specification/issues/31#issuecomment-548360553" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>In the event that a server can’t apply an ACL to a resource, it MUST deny access. [<a href="https://github.com/solid/specification/issues/130#issue-532777017" rel="cito:citesAsSourceDocument">Source</a>]</p>
<p>Servers exposing client’s access privileges on a resource URL MUST advertise by including the <code>WAC-Allow</code> HTTP header in the response of HTTP <code>HEAD</code> and <code>GET</code> requests.</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>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.</p>
<p>Clients' parsing algorithm for the <code>WAC-Allow</code> header should incorporate error handling. When the received message fails to match an allowed pattern, finds unrecognised access parameters or access modes, clients MUST ignore the received <code>WAC-Allow</code> header-field.</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>
<p class="issue">Shape of ACL: https://github.com/solid/specification/issues/169</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>
<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>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 security implications.</p>
<p>A data pod MUST NOT assume that HTTP request headers sent by a client are valid, and MUST reject or sanitize invalid header values before processing them or incorporating them in messages sent to others. For example, values for <code>Host</code> and <code>Origin</code> MUST NOT be assumed to be free of possibly malicious sequences such as <code>/..</code> or others, and invalid <code>Origin</code> values MUST NOT be echoed into the <code>Access-Control-Allow-Origin</code> response header.</p>
<p>A data pod MUST NOT assume 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>Solid data pods <a href="#cors-server">disable all cross-origin protections</a> in browsers because resource access is governed explicitly by <a href="#web-access-control">Web Access Control</a>. As such, data pods MUST NOT rely on browser-based cross-origin protection mechanisms for determining the authentication status or representation of a resource. In particular, they MUST ignore HTTP cookies from untrusted origins. Additional security measures MAY be taken to prevent metadata in error responses from leaking. For instance, a malicious app 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 data pod MAY set the status code of error responses to <code>404</code> and/or anonymize or censor their contents.</p>
<p>Data pods SHOULD 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">
<section id="identifiable-information" inlist="" rel="schema:hasPart" resource="#identifiable-information">
<h4 property="schema:name">Identifiable Information</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>In order to prevent leakage of non-resource data, error responses SHOULD NOT contain identifiable information.</p>
</div>
</section>
</div>
</section>
<section id="accessibility-considerations" inlist="" rel="schema:hasPart" resource="#accessibility-considerations">
<h3 property="schema:name">Accessibility Considerations</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>..</p>
</div>
</section>
<section id="internationalization-considerations" inlist="" rel="schema:hasPart" resource="#internationalization-considerations">
<h3 property="schema:name">Internationalization Considerations</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>..</p>
</div>
</section>
<section id="security-privacy-review" inlist="" rel="schema:hasPart" resource="#security-privacy-review">
<h3 property="schema:name">Security and Privacy Review</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>..</p>
</div>
</section>
</div>
</section>
<section class="appendix" id="references" inlist="" rel="schema:hasPart" resource="#references">
<h2>References</h2>
<div datatype="rdf:HTML" property="schema:description">
<section id="normative-references" inlist="" rel="schema:hasPart" resource="#normative-references">
<h3 property="schema:name">Normative References</h3>
<div datatype="rdf:HTML" property="schema:description">
<dl class="bibliography" resource="">
<dt id="bib-fetch">[FETCH]</dt>
<dd>Anne van Kesteren. <a href="https://fetch.spec.whatwg.org/">Fetch Standard</a>. Living Standard. URL: <a href="https://fetch.spec.whatwg.org/">https://fetch.spec.whatwg.org/</a></dd>
<dt id="bib-w3c-html">[W3C-HTML]</dt>
<dd><a href="https://www.w3.org/TR/html/">HTML</a>. 28 January 2021. W3C Recommendation. URL: <a href="https://www.w3.org/TR/html/">https://www.w3.org/TR/html/</a> ED: <a href="https://html.spec.whatwg.org/">https://html.spec.whatwg.org/</a></dd>
<dt id="bib-json-ld11">[JSON-LD11]</dt>
<dd>Gregg Kellogg; Pierre-Antoine Champin. <a href="https://www.w3.org/TR/json-ld11/">JSON-LD 1.1</a>. 9 September 2019. WD. URL: <a href="https://www.w3.org/TR/json-ld11/">https://www.w3.org/TR/json-ld11/</a></dd>
<dt id="bib-ldn">[LDN]</dt>
<dd>Sarven Capadisli; Amy Guy. <a href="https://www.w3.org/TR/ldn/">Linked Data Notifications</a>. 2 May 2017. REC. URL: <a href="https://www.w3.org/TR/ldn/">https://www.w3.org/TR/ldn/</a></dd>
<dt id="bib-ldp">[LDP]</dt>
<dd>Steve Speicher; John Arwe; Ashok Malhotra. <a href="https://www.w3.org/TR/ldp/">Linked Data Platform 1.0</a>. 26 February 2015. REC. URL: <a href="https://www.w3.org/TR/ldp/">https://www.w3.org/TR/ldp/</a></dd>
<dt id="bib-rdf-schema">[RDF-SCHEMA]</dt>