Add introduction section

lws10-core/index.html

@@ -115,7 +115,29 @@ <h2>Document Conventions</h2>
     <section id="introduction">
       <h2>Introduction</h2>
       <p>
+        This specification defines the Linked Web Storage (LWS) Protocol, which enables client applications to access and manage web resources, based on the identity and permissions of an agent.
       </p>
+      <p>
+        By standardising how an LWS server manages and provides access to a hierarchy of linked resources, the protocol enables users to use different LWS client applications to interact with the same stored data. These linked resources are defined through containers and containment relationships that describe where things are located, and metadata that describes how the resources relate to each other.
+      </p>
+      <p>
+        The protocol defines standard operations on these resources to create, read, update, and delete. Resources, their containment, and their metadata are managed by the server as a set of JSON-LD documents (and other representations). Each resource is identified by a URI. A client navigates the resource hierarchy from a root container, discovering contained resources and their relations through links provided in server responses.
+      </p>
+      <p>
+        A agent's identity is confirmed through an identity provider that can be external to the Linked Web Storage server. This separation means the server does not manage credentials directly; rather, it receives and validates a signed authentication credential as a token issued by a trusted identity provider. A user can therefore present their existing identity to any compliant server, without needing a new or existing separate account on that server. User authentication is defined in companion specifications for OpenID Connect, SAML 2.0, and self-signed controlled identifiers (CIDs).
+      </p>
+      <p>
+        Authorization determines whether a requesting agent has permission to access a resource or perform an operation on it. A compliant LWS server designates a resource manager for each resource that determines whether a resource is private (i.e., available only to its owner), restricted (i.e., available to a defined set of users), or public (i.e., available to any user). The server enforces the access decisions of the resource manager when handling each client request.
+      </p>
+      <p>This specification is intended to be used by:</p>
+      <ul>
+        <li>Developers building client applications that access an agent's LWS resources</li>
+        <li>Server implementers building compliant LWS servers that mediate access to an agent's web resources</li>
+      </ul>
+      <p>
+        Different compliant servers each maintain their own hierarchy of linked resources. An agent can navigate across servers using the same identity, with access to each server's resources determined by the permissions granted by that servers resource managers.
+      </p>
+
 
       <section id="resource-access">
         <h2>Resource Access</h2>
@@ -203,7 +225,7 @@ <h2>Terminology</h2>
 
       <div class="issue atrisk" title="Section may be removed">
       <p>
-        This specification defines <a>operations</a> on <a>served resources</a>, the resulting change of state, and a <a>response</a> intended to give the <a>requesting agent</a> requested infomation or inform them of the outcome of the <a>operation</a>.
+        This specification defines <a>operations</a> on <a>served resources</a>, the resulting change of state, and a <a>response</a> intended to give the <a>requesting agent</a> requested information or inform them of the outcome of the <a>operation</a>.
         An <dfn>operation</dfn> is any of the following actions that can be performed on a <a>served resource</a>:
       </p>
       <ul>
@@ -214,7 +236,7 @@ <h2>Terminology</h2>
       </ul>
 
       <p>
-        The folowing section will describe the semantics and <dfn>responses</dfn> of these operations but the following <dfn>core responses</dfn> apply to any operation:
+        The following section will describe the semantics and <dfn>responses</dfn> of these operations but the following <dfn>core responses</dfn> apply to any operation:
       </p>
       <ul>
         <li><dfn>success</dfn> - the operation is believed to have completed. This may be accompanied by a <dfn>resource representation</dfn> conveying the contents of a <a>served resource</a>. A <a>success</a> response is not defined for the <a>create resource</a> operation. See instead <a href="#dfn-created">created</a>.</li>