You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>A <dfnclass="dfn-paneled" data-dfn-type="dfn" id="data-pod">data pod</dfn> is aplace for storing documents, with mechanisms for controlling who can access what.</p>
333
+
<p>A <dfnclass="dfn-paneled" data-dfn-type="dfn" id="data-pod">data pod</dfn> is aplace for storing documents, with mechanisms for controlling who can access what.</p>
334
334
335
335
<p>A <dfnclass="dfn-paneled" data-dfn-type="dfn" id="solid-app">Solid app</dfn> is an application that reads or writes data from one or more <adata-link-type="dfn" href="#data-pod" id="ref-for-data-pod">data pods</a>.</p>
336
336
@@ -406,7 +406,7 @@ <h2 property="schema:name">Hypertext Transfer Protocol</h2>
<p>A <adata-link-type="dfn" href="#data-pod" id="ref-for-data-pod①">data pod</a> MUST be an HTTP/1.1 server[<cite><aclass="bibref" href="#bib-rfc7230">RFC7230</a></cite>][<cite><aclass="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. It SHOULD additionally be an HTTP/2 server [<cite><aclass="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>
409
+
<p>A <adata-link-type="dfn" href="#data-pod" id="ref-for-data-pod①">data pod</a> MUST be an HTTP/1.1 server[<cite><aclass="bibref" href="#bib-rfc7230">RFC7230</a></cite>][<cite><aclass="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. It SHOULD additionally be an HTTP/2 server [<cite><aclass="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>
410
410
411
411
<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 Solid client MUST be an HTTP/1.1 client[<cite><aclass="bibref" href="#bib-rfc7230">RFC7230</a></cite>][<cite><aclass="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. It MAY additionally be an HTTP/2 client [<cite><aclass="bibref" href="#bib-rfc7540">RFC7540</a></cite>] to improve performance.</p>
424
+
<p>A Solid client MUST be an HTTP/1.1 client[<cite><aclass="bibref" href="#bib-rfc7230">RFC7230</a></cite>][<cite><aclass="bibref" href="#bib-rfc7231">RFC7231</a></cite>]. It MAY additionally be an HTTP/2 client [<cite><aclass="bibref" href="#bib-rfc7540">RFC7540</a></cite>] to improve performance.</p>
425
425
426
426
<p>A Solid client MAY implement the client parts of <cite>HTTP/1.1 Conditional Requests</cite> [<cite><aclass="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><aclass="bibref" href="#bib-rfc7234">RFC7234</a></cite>] and <cite>HTTP/1.1 Range Requests</cite> [<cite><aclass="bibref" href="#bib-rfc7233">RFC7233</a></cite>] to improve performance.</p>
<p><adata-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 asecurity mechanism that ensures malicious websites cannot simply read your profile or banking details from other websites. However, this reasonable default poses aproblem even for benevolent Solid apps, which might have good reasons to access data from different places. For instance, aSolid 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>
711
+
<p><adata-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 asecurity mechanism that ensures malicious websites cannot simply read your profile or banking details from other websites. However, this reasonable default poses aproblem even for benevolent Solid apps, which might have good reasons to access data from different places. For instance, aSolid 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>
712
712
713
713
<p>For cases where the other origins have their own access protection mechanism — <ahref="#authorization">like within Solid</a> — the browser’s built-in cross-origin protection is actually an obstacle rather than a feature. After all, <adata-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>
714
714
715
-
<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><aclass="bibref" href="#bib-fetch">FETCH</a></cite>]. By responding to browser requests with aspecific combination of HTTP headers, servers can indicate which actions are allowed for agiven resource. For a Solid data pod, the goal is to allow <em>all</em> actions on the CORS level, such that the deeper <ahref="#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>
715
+
<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><aclass="bibref" href="#bib-fetch">FETCH</a></cite>]. By responding to browser requests with aspecific combination of HTTP headers, servers can indicate which actions are allowed for agiven resource. For a Solid data pod, the goal is to allow <em>all</em> actions on the CORS level, such that the deeper <ahref="#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>
<p>A <adata-link-type="dfn" href="#data-pod" id="ref-for-data-pod③">data pod</a> MUST implement the CORS protocol[<cite><aclass="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 aresource, 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><aclass="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</p>
720
+
<p>A <adata-link-type="dfn" href="#data-pod" id="ref-for-data-pod③">data pod</a> MUST implement the CORS protocol[<cite><aclass="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 aresource, 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><aclass="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</p>
721
721
722
722
<pclass="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 <ahref="https://github.com/whatwg/fetch/issues/878">proposal</a> to mitigate this has been suggested.</p>
723
723
724
-
<p>Concretely, whenever adatapod receives an HTTP request containing a valid <code>Origin</code> header [<cite><aclass="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><aclass="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). Adatapod MUST also support the HTTP <code>OPTIONS</code> method [<cite><aclass="bibref" href="#bib-rfc7231">RFC7231</a></cite>] such that it can respond appropriately to CORS preflight requests.</p>
724
+
<p>Concretely, whenever adatapod receives an HTTP request containing a valid <code>Origin</code> header [<cite><aclass="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><aclass="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). Adatapod MUST also support the HTTP <code>OPTIONS</code> method [<cite><aclass="bibref" href="#bib-rfc7231">RFC7231</a></cite>] such that it can respond appropriately to CORS preflight requests.</p>
725
725
726
726
<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>
<p>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>
899
899
900
-
<p>Servers are strongly discouraged from assuming that the user agent is aregular Webbrowser, 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 anon-browser actor unaffected by browser security constraints.</p>
900
+
<p>Servers are strongly discouraged from assuming that the user agent is aregular Webbrowser, 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 anon-browser actor unaffected by browser security constraints.</p>
901
901
902
-
<p>Servers <ahref="#cors-server">disable all cross-origin protections</a> in browsers because resource access is governed explicitly by the <ahref="#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>
902
+
<p>Servers <ahref="#cors-server">disable all cross-origin protections</a> in browsers because resource access is governed explicitly by the <ahref="#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>
903
903
904
904
<p>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>
0 commit comments