--- a/spec/tls-respec.html Mon Jul 01 14:40:18 2013 +0200
+++ b/spec/tls-respec.html Mon Jul 01 15:28:16 2013 +0200
@@ -714,26 +714,26 @@
<img width="90%" src="img/WebIDSequence-friendly.png">
<p>The steps in detail are as follows:</p>
<ol>
- <li><tref>Bob</tref>'s <tref>Client</tref> MUST open a TLS [[!TLS]] connection with the server which authenticates itself using well known TLS mechanisms.
- This MAY be done as the first part of an HTTPS connection [[!HTTP-TLS]].
+ <li><tref>Bob</tref>'s <tref>Client</tref> MUST open a TLS [[!TLS]] connection with the server which authenticates itself using the standard TLS protocol.
</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]].
</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.
+ The <tref>Guard</tref> can then intercept that request and by checking access control rules associated with that resource, determine if the client needs authorization and hence authentication for that type of request.
+ If the request has no access restrictions the request can be passed straight on to the resource.
+ If the request does have access restrictions then the <tref>Guard</tref> can proceed to the next step.
</li>
<li>If the resource requires WebID authentication, the Guard MAY 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>The <tref>Guard</tref> 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>
- <li>The Client asks Bob to choose a certificate if the choice has not been automated.
+ <li>The <tref>Client</tref> asks Bob to choose a certificate if the choice has not been automated.
We will assume that Bob does choose a <tref>WebID Certificate</tref> and sends it to the client.
</li>
<li>The <tref>TLS Agent</tref> MUST verify that the client is indeed in possession of the private key.
What is important here is that the <tref>TLS Agent</tref> need not know the Issuer of the Certificate, or need not have any trust relation with the Issuer.
- Indeed if the TLS Layer could verify the signature of the Issuer and trusted the statements it signed, then step 4 and 5 would not be needed - other than perhaps as a way to verify that the key was still valid.
+ Indeed if the TLS Layer could verify the signature of the Issuer and trusted the statements it signed, then step 5 and 6 would not be needed - other than perhaps as a way to verify that the key was still valid.
</li>
<li>The <tref>WebID Certificate</tref> is then passed on to the <tref>Guard</tref> with the provision that the <tref>WebID</tref> still needs to be verified.
</li>
@@ -779,7 +779,7 @@
<p>This section covers details about each step in the authentication process.
</p>
-<section class='normative'>
+<section class='informative'>
<h2>Initiating a TLS Connection</h2>
<p>Standard SSLv3 and TLSv1 and upwards can be used to establish the connection between
@@ -796,18 +796,27 @@
Please see the <a href="http://www.w3.org/2005/Incubator/webid/wiki/">WebID Wiki</a> for implementation pointers in different programming languages and platforms to learn about how this can be done and to share your experience.</p>
</section>
-<section class='normative'>
+<section class='informative'>
<h2>Connecting at the Application Layer</h2>
<p>Once the TLS connection has been setup, the application layer protocol interaction can start.
-This could be an HTTP GET request on the protected resource for example.
+This could be an HTTP GET request on the protected resource for example.</p>
<p>If the protocol permits it, the Client can let the Application layer, and especially the <tref>Guard</tref> know that the client can authenticate with a <tref>WebID Certificate</tref>, and even if it wishes to do so. This may be useful both to allow the Server to know that it can request the client certificate, and also in order to make life easier for Robots that may find it a lot more convenient to be authenticated at the TLS layer.
</p>
<p class="issue">Bergi proposed a header for HTTP which could do this. Please summarise it. </p>
</section>
-
-<section class='normative'>
+<section class='informative'>
+<h2>Access Control Check</h2>
+<p>The <tref>Guard</tref> can intercept the request and consult its access control rules for that resource, in order to determine if some the request type is access controled.
+If the request is authorized to anyone then server can pass the request straight on to the resource.
+If the request requires some authentication the Guard MAY request the client certificate as detailed
+in the next section. </p>
+<p>Because a <tref>WebID</tref> is a global linkable URI, one can build webs of trust that can be crawled the same way the web can be crawled: by following links from one document to another.
+It is therefore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friends and those friends' friends (FOAF), stated by them at their domains.
+It is even possible to allow remote agents to define their own access control rules for parts of the machine's namespace.</p>
+</section>
+<section class='informative'>
<h2>Requesting the Client Certificate</h2>
<p>TLS allows the server to request a Certificate from the Client using the <code>CertificateRequest</code> message [Section 7.4.4] of TLS v1.1 [[!TLS]]. Since WebID TLS authentication does not rely on CAs signing the certificate to verify the <tref>WebID Claim</tref>s made therein, the Server does not need to restrict the certificate it receives by the CAs they were signed by. It can therefore leave the <code>certificate_authorities</code> field blank in the request. </p>
@@ -909,16 +918,11 @@
<p>For triples stores that do not normalize literals on loading a graph, the normalization will need to be done after the query results and before matching those with the values from the <tref>Certificate</tref>. Because one could not rely on the modulus having been normalized, one would have to start with the <tref>WebID</tref> - <code>bob:me</code> and find all it's <code>cert:key</code> relations to objects - which we know to be keys - and then iterate through each of those keys' modulus and exponent, and verify if the normalized version of the value of those relation is equal to the numbers found in the certificate. If one such key is found then the answer is <code>true</code>, otherwise the answer will be <code>false</code>.</p>
</section>
</section>
-<section class='normative'>
+<section class='informative'>
<h2>Authorization</h2>
-<p>The Authorization step may be as simple as just allowing everybody read access. The authentication phase may then just have been useful in order to gain some extra information from the <tref>WebID Profile</tref> in order to personalize a site -- e.g. displaying a user's picture.</p>
-<p>Once the <tref>Guard</tref> has a <tref>WebID</tref> he can do a lookup in a database to see if the agent is allowed the required access to the given resource.
+<p>Once the <tref>Guard</tref> has a <tref>WebID</tref> it can lookup the access control rules for the given resource to see if the agent is allowed the required type of access.
Up to this point we are not much more advanced that with a user name and password, except that the user did not have to create an account on Alice's server to identify himself and that the server has some claimed attributes to personalize the site for the requestor.
-But the interesting thing about such a <tref>WebID</tref> is that because it is a global linkable URI, one can build webs of trust that can be crawled the same way the web can be crawled: by following links from one document to another.
-It is therefore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friends and those friends' friends (FOAF), stated by them at their domains.
-It is even possible to allow remote agents to define their own access control rules for parts of the machine's namespace.
-There are too many possibilities to list them all here.
</p>