Indicate creator via HTTP Link header

ED/protocol.html

@@ -836,7 +836,7 @@ <h4 property="schema:name">Description Resource</h4>
                       <p>An auxiliary resource of type <em>Description Resource</em> provides a description of a subject resource.</p>
                       <p about="" id="server-description-resource-max" rel="spec:requirement" resource="#server-description-resource-max"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> directly associate more than one description resource to a subject resource.</span></p>
                       <p about="" id="server-description-resource-authorization" rel="spec:requirement" resource="#server-description-resource-authorization"><span property="spec:statement">When an HTTP request targets a description resource, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> apply the authorization rule that is used for the subject resource with which the description resource is associated.</span></p>
-                      <p about="" id="server-description-resource-creator" rel="spec:requirement" resource="#server-description-resource-creator"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="#Server">server</span> indicates the <a href="#creator">creator</a> of a resource created by a successful request from an authenticated <a href="#agent">agent</a>, the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include a statement with the <code>dcterms:creator</code> property, whose subject is the created resource and whose object is the authenticated agent, in the associated description resource.</span> [<a href="https://github.com/solid/specification/issues/315" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/66" rel="cito:citesAsSourceDocument">Source</a>]</p>
+                      <p about="" id="server-link-header-creator" rel="spec:requirement" resource="#server-link-header-creator"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="#Server">server</span> indicates the <a href="#creator">creator</a> of a resource created by a successful request from an authenticated <a href="#agent">agent</a>, the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include an HTTP Link header field with <code>rel="http://purl.org/dc/terms/#creator"</code> targeting the WebID of the authenticated agent.</span> [<a href="https://github.com/solid/specification/issues/315" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/66" rel="cito:citesAsSourceDocument">Source</a>]</p>
                       <p about="" id="client-link-describes" rel="spec:requirement" resource="#client-link-describes">Clients can discover resources that are described by description resources by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking the HTTP <code>Link</code> header field 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>
@@ -880,7 +880,6 @@ <h3 property="schema:name">Writing Resources</h3>
                   <p><span about="" id="server-post-container" rel="spec:requirement" resource="#server-post-container"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> allow creation of new resources by a <code>POST</code> request to a URI path ending with <code>/</code>.</span></span> <span about="" id="server-post-container-create-resource" rel="spec:requirement" resource="#server-post-container-create-resource"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create resources with URI paths ending with <code>/{id}</code> in container <code>/</code>.</span></span> [<a href="https://github.com/solid/specification/pull/160#issuecomment-636822687" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/190" rel="cito:citesAsSourceDocument">Source</a>]</p>
                   <p about="" id="server-post-target-not-found" rel="spec:requirement" resource="#server-post-target-not-found"><span property="spec:statement">When a <code>POST</code> method request targets a resource without an existing representation, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with the <code>404</code> status code.</span> [<a href="https://github.com/solid/specification/issues/108#issuecomment-549448159" rel="cito:citesAsSourceDocument">Source</a>]</p>
                   <p about="" id="server-put-patch-auxiliary-resource" rel="spec:requirement" resource="#server-put-patch-auxiliary-resource"><span property="spec:statement">When a <code>PUT</code> or <code>PATCH</code> request targets an auxiliary resource, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> create or update it.</span> [<a href="https://github.com/solid/specification/issues/42#issuecomment-616688848" rel="cito:citesAsSourceDocument">Source</a>]</p>
-                  <p about="" id="server-protect-creator" rel="spec:requirement" resource="#server-protect-creator"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> allow HTTP <code>PUT</code> or <code>PATCH</code> to update <a href="#creator">creator</a> statements in a description resource; if the server receives such a request, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span> [<a href="https://github.com/solid/specification/issues/315" rel="cito:citesAsSourceDocument">Source</a>]</p>
                   <p><span about="" id="server-protect-containment" rel="spec:requirement" resource="#server-protect-containment"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> allow HTTP <code>PUT</code> or <code>PATCH</code> on a container to update its containment triples; if the server receives such a request, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid/specification/issues/40#issuecomment-573358652" rel="cito:citesAsSourceDocument">Source</a>]</p>
                   <p about="" id="server-protect-contained-resource-metadata" rel="spec:requirement" resource="#server-protect-contained-resource-metadata"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> allow HTTP <code>POST</code>, <code>PUT</code> and <code>PATCH</code> to update a container’s <a href="#contained-resource-metadata-statements">resource metadata statements</a>; if the server receives such a request, it MUST respond with a <code>409</code> status code.</span> [<a href="https://github.com/solid/specification/issues/227#issuecomment-919312592" rel="cito:citesAsSourceDocument">Source</a>]</p>
                   <div class="note" id="conditional-update" inlist="" rel="schema:hasPart" resource="#conditional-update">
@@ -1133,7 +1132,7 @@ <h3 property="schema:name">Security Considerations</h3>
                     <span about="" id="cors-protections-authorization" rel="spec:advisement" resource="#cors-protections-authorization"><span property="spec:statement">Servers <a href="#cors-server">disable all cross-origin protections</a> in browsers because resource access is governed explicitly by the <a href="#authorization">Authorization</a> component. As such, servers <span rel="spec:advisementLevel" resource="spec:Cannot">cannot</span> rely on browser-based cross-origin protection mechanisms for determining the authentication status or representation of a resource.</span></span>
 
                     <span about="" id="cors-untrusted-origins-ignore-cookies" rel="spec:advisement" resource="#cors-untrusted-origins-ignore-cookies"><span property="spec:statement">In particular, servers are <span rel="spec:advisementLevel" resource="spec:StronglyEncouraged">strongly encouraged</span> to ignore HTTP cookies from untrusted origins.</span></span>
- 
+
                     <span about="" id="cors-untrusted-origins-minmise-error-leaking" rel="spec:advisement" resource="#cors-untrusted-origins-minmise-error-leaking"><span property="spec:statement">Additional security measures <span rel="spec:advisementLevel" resource="spec:Can">can</span> 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.</span></span></p>
                   <p about="" id="tls-connections" rel="spec:advisement" resource="#tls-connections"><span property="spec:statement">Servers are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> 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 server is behind a reverse proxy that terminates a secure connection.</span></p>
                 </div>
@@ -1146,7 +1145,7 @@ <h3 property="schema:name">Privacy Considerations</h3>
                   <p about="" id="authorization-resources" rel="spec:advisement" resource="#authorization-resources"><span property="spec:statement">Servers are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to use authorization techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.</span></p>
                   <p about="" id="identifiable-information-error-responses" rel="spec:advisement" resource="#identifiable-information-error-responses"><span property="spec:statement">To prevent leakage of non-resource data, servers are <span rel="spec:advisementLevel" resource="spec:StronglyDiscouraged">strongly discouraged</span> from including identifiable information in error responses.</span></p>
                   <p about="" id="webid-profile-privacy" rel="spec:advisement" resource="#webid-profile-privacy"><span property="spec:statement">The decision to include or exclude any information (e.g., storage, inbox) in a WebID Profile served from a Solid storage lies with the Agent controlling the WebID (or the URI owner). A URI allocated to a WebID in a Solid storage does not imply that the WebID is the storage owner. Owners of a WebID hosted from Solid storage are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to consider information related to themselves that could be readable from other resources in the storage, even if that information (e.g., storage, inbox) is not part of the WebID Profile itself (see <a href="#storage-owner-uri-ownership">Storage Owner and URI Ownership</a> and <a href="#self-describing-resources">Self-describing Resources</a>.)</span></p>
-                  <p about="" id="creator-privacy" rel="spec:advisement" resource="#creator-privacy"><span property="spec:statement">The <a href="#creator">creator</a> of a resource reveals information about an agent’s identity and activity. Disclosure of the creator through a description resource is subject to the same authorization rule as the subject resource. Servers are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to make their attribution practice known to agents. URI owners <span rel="spec:advisementLevel" resource="spec:Can">can</span> take measures beyond what is defined by this specification to determine what information is retained, for example, removing an existing attribution to meet data protection obligations.</span></p>
+                  <p about="" id="creator-privacy" rel="spec:advisement" resource="#creator-privacy"><span property="spec:statement">The <a href="#creator">creator</a> of a resource reveals information about an agent’s identity and activity. Disclosure of the creator through an HTTP Link header field is subject to the same authorization rule as the subject resource. Servers are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to make their attribution practice known to agents. URI owners <span rel="spec:advisementLevel" resource="spec:Can">can</span> take measures beyond what is defined by this specification to determine what information is retained, for example, removing an existing attribution to meet data protection obligations.</span></p>
                   <p about="" id="report-legal-obstacles" rel="spec:advisement" resource="#report-legal-obstacles"><span property="spec:statement">Servers are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to respond with the <code>451</code> status code and, where appropriate, identify the entities implementing the blocking to provide transparency in cases where legal or public policy issues affect server operations, as outlined in <cite><a href="https://www.rfc-editor.org/rfc/rfc7725.html" rel="cito:citesAsAuthority">Report Legal Obstacles</a></cite>, while avoiding the disclosure of sensitive legal or privacy-related details [<cite><a class="bibref" href="#bib-rfc7725">RFC 7725</a></cite>].</span></p>
                 </div>
               </section>
@@ -1322,13 +1321,8 @@ <h2 property="schema:name">Changelog</h2>
                   </tr>
                   <tr about="#d74c7d63-67a0-41fb-ac20-a70e612b2dfe" typeof="spec:Change">
                     <td><a href="https://www.w3.org/policies/process/#class-4" rel="spec:changeClass">4</a></td>
-                    <td><a href="#server-description-resource-creator" rel="spec:changeSubject">#server-description-resource-creator</a></td>
-                    <td property="spec:statement">Add requirement for server to record the <a href="#server-description-resource-creator">creator in the associated description resource</a>.</td>
-                  </tr>
-                  <tr about="#f46e3ef2-215f-41b0-9098-c4f5049e4dd6" typeof="spec:Change">
-                    <td><a href="https://www.w3.org/policies/process/#class-4" rel="spec:changeClass">4</a></td>
-                    <td><a href="#server-protect-creator" rel="spec:changeSubject">#server-protect-creator</a></td>
-                    <td property="spec:statement">Add requirement for server to protect <a href="#server-protect-creator">creator statements in a description resource</a>.</td>
+                    <td><a href="#server-link-header-creator" rel="spec:changeSubject">#server-link-header-creator</a></td>
+                    <td property="spec:statement">Add requirement for server for how to indicate the <a href="#server-link-header-creator">creator of a resource</a>.</td>
                   </tr>
                   <tr about="#c5e1c7a2-55ed-459b-b0dd-669eda9737df" typeof="spec:Change">
                     <td><a href="https://www.w3.org/policies/process/#class-2" rel="spec:changeClass">2</a></td>