Add editors draft for LWS Access Requests and Access Grants (#106)

* Add editors draft for LWS Access Requests and Access Grants

* Remove REST binding reference

* Add security consideration about spam and other unwanted content

* Add affiliations

* Adjust LWS-Core reference

* Update lws10-access-requests/index.html

Co-authored-by: Christoph Braun <braun@kit.edu>

* Add missing w3cid property for editor

* Add support for target object structures

* Adjust authorization requirements/recommendations

* Update lws10-access-requests/index.html

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>

* Separate data model and serialization

* Remove normative authorization section

* Remove data validation requirements

* Support multi-valued access properties

* Clarify conformsTo text and examples

* Adjust discovery requirements

* Remove non-normative implementation detail

* Simplify profile and policy terms

* Remove TypeIndex examples until we have more clarity on the type index feature

* Adjust terminology to use storage controller

* Move hasConstraint from access object into ODRL constraint structure

* Integrate access requests into main specification document

* Remove old sections

* Add access request content

* Update lws10-core/Privacy-Considerations.html

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>

* Fix duplicate definition for echidna check

---------

Co-authored-by: Christoph Braun <braun@kit.edu>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>

Author: 3 people

lws10-core/Discovery.html

@@ -2,7 +2,7 @@
   <h3>Storage Description Resource</h3>
 
   <p>
-    A <dfn>storage description resource</dfn> provides information a client can use
+    A <a>storage description resource</a> provides information a client can use
     when interacting with a storage, including descriptions of capabilities and
     service endpoints.
   </p>

lws10-core/Privacy-Considerations.html

@@ -20,3 +20,24 @@
   to correlate requests. When using pseudonymous identifiers, the authorization server will need to be careful not to issue the same identifier more than once.
 </p>
 
+<section id="privacy-access-requests" class="informative">
+  <h4>Access Requests and Grants</h4>
+
+  <ul>
+    <li>
+      An <a>access request</a> or <a>access grant</a> can reveal sensitive information
+      about the resources, agents, and purposes involved. Servers are encouraged to limit
+      the visibility of these resources to authorized parties, such as the storage controller
+      and the assignee identified in the document. For example, a storage controller might
+      have the ability to read and delete all resources, while other agents would only have
+      access to the resources for which they are the assignee.
+    </li>
+    <li>
+      When an <a>access grant</a> includes a client constraint, it is advisable for a
+      server to filter that grant from responses to requests made by other clients. For
+      example, if an agent is granted access to a resource only when using a specific
+      client, that grant would not be visible when the agent uses a different client.
+    </li>
+  </ul>
+</section>
+

lws10-core/Security-Considerations.html

@@ -31,3 +31,28 @@ <h4>Token Security</h4>
   </ul>
 </section>
 
+<section id="security-access-requests" class="informative">
+  <h4>Access Requests and Grants</h4>
+
+  <ul>
+    <li>
+      Servers are strongly encouraged to apply authorization rules to both the
+      <a>access request</a> and <a>access grant</a> endpoints. Write access to the
+      <a>access grant</a> endpoint, in particular, should be restricted to authorized
+      storage controllers and specific clients.
+    </li>
+    <li>
+      When an agent creates an <a>access request</a>, the server is encouraged to verify
+      that the <code>assignee</code> value in the request is associated with the
+      authenticated identity of the requesting agent.
+    </li>
+    <li>
+      Because the <a>access request</a> endpoint accepts content from external agents,
+      servers are encouraged to implement measures to prevent abuse, such as rate limiting,
+      payload size restrictions, or requiring authentication before accepting submissions.
+      Without such protections, the endpoint may be vulnerable to spam, resource exhaustion,
+      or other forms of unwanted content.
+    </li>
+  </ul>
+</section>
+

lws10-core/index.html

@@ -273,6 +273,11 @@ <h2>Delete resource</h2>
 	  <div data-include="Operations/rest-table.md" data-include-format="markdown" data-include-replace="true"></div>
     </section>
 
+    <section id="access-requests-and-grants">
+      <h2>Access Requests and Grants</h2>
+      <div data-include="lws-access-requests.html" data-include-replace="true"></div>
+    </section>
+
     <section id="lws-media-type">
       <h2>LWS Media Type</h2>
 	  <div data-include="lws-media-type.md" data-include-format="markdown" data-include-replace="true"></div>