Binary file spec/img/WebIDSequence-friendly.graffle has changed

Binary file spec/img/WebIDSequence-friendly.jpg has changed

--- a/spec/tls-respec.html	Sun Jun 30 22:43:21 2013 -0400
+++ b/spec/tls-respec.html	Mon Jul 01 13:54:52 2013 +0200
@@ -719,10 +719,12 @@
     </li>
     <li>Once the Transport Layer Security [TLS] has been set up, the application protocol exchange can start.
         If the protocol is HTTP then the client can request an HTTP GET, PUT, POST, DELETE, ... action on a resource as detailed by [[!HTTP11]].
-        The <tref>Guard</tref> can then intercept that request and by checking some access control rules determine if the client needs authorization and hence authentication.
+    </li>
+    <li>
+        The <tref>Guard</tref> can then intercept that request and by checking access control rules associated with that type of request, determine if the client needs authorization and hence authentication.
         We will consider the case here where the client does need to be authenticated.
     </li>
-    <li>The Guard MUST request the client to authenticate itself using public key cryptography by signing a token with its private key and have the Client send its Certificate. This has been carefully defined in the TLS protocol and can be summarized by the following steps:
+    <li>If the resource requires some form of authentication, the Guard MUST request the client to authenticate itself using public key cryptography by signing a token with its private key and have the Client send its Certificate. This has been carefully defined in the TLS protocol and can be summarized by the following steps:
         <ol>
             <li>The guard requests the TLS agent to make a Certificate Request to the client. The TLS layer does this. Because the WebID-TLS protocol does not rely on Certificate Authorities to verify the contents of the <tref>Certificate</tref>, the <tref>TLS Agent</tref> can ask for any Certificate from the Client. More details in <a href="#requesting-the-client-certificate">Requesting the Client Certificate</a>
             </li>
@@ -764,11 +766,9 @@
             a request to an up to date graph.
         </li>
     </ol>
-    <li>With the set of verified <tref>WebID</tref>s the Guard can then check its access control rules using information from the web and other information available to it, to verify if the referent of the <tref>WebID</tref> is indeed allowed access to the protected resource.
-    The exact nature of those Access Control Rules is left for another specification.
-    Suffice it to say that it can be something as simple as a lookup in a table.
+    <li>With the set of verified <tref>WebID</tref>s the Guard can then check if one of  of them is authorized by the Access Control Rules found in step 2.
     </li>
-    <li>If access is granted, then the guard can pass on the request to the protected resource, which can then interact unimpeded with the client.
+    <li>If access is granted, then the guard can pass on the request to the protected resource.
     </li>
 </ol>
 </section>