--- a/spec/index-respec.html	Tue Jan 10 12:36:29 2012 +0100
+++ b/spec/index-respec.html	Tue Jan 10 13:47:58 2012 +0100
@@ -421,7 +421,7 @@
 Finally the Guard can grant or deny access according to how the verfied identities satisfy the Access Control Rules. 
 </dd>
 
-<dt><tdef>WebID Claim</tdef></dt>
+<dt><tdef>WebID Claim</tdef> or <tdef>Claimed WebID</tdef></dt>
 <dd>A <tref>WebID Certificate</tref> can be thought of a set of statements made and signed by a <tref>Certificate Authority</tref>. 
 If the Certificate Authority is not known to be one whose every statement can be trusted, then the statements in the certificate must be thought of by a suspicious guard, as claimed statements only, that is as statements which have not been verified. 
 In particular statements about the Subject Alternative Names of the agent that knows the private key, should not be assumed to be true until verified. 
@@ -766,21 +766,34 @@
 <li>The Guard MUST requests 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 summarised by the following steps:
 <ol>
 <li>The guard requests of the TLS agent that it make a Certificate Request to the client. The TLS layer does this. Because the WebID 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. 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.</li>
+<li>The Client 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.
+</li>
 <li>The <tref>WebID Certificate</tref> is then passed on to the <tref>Guard</tref> with the proviso that the WebIDs still needs to be verified.</li>
 </ol>
 </li>
-<li>The <tref>Guard</tref> then MUST ask the <tref>Verification Agent</tref> to verify that the WebIDs do identify the agent who knows the given public key.</li>
-<li>The WebID is verified by looking up the definition of the URL at its canonical location. This can be done by dereferencing it. The <tref>Verification Agent</tref> MUST extract the <tref>public key</tref> and all the URI entries contained in the <code>Subject Alternative Name</code> extension of the <tref>WebID Certificate</tref>.  A <tref>WebID Certificate</tref> MAY contain multiple URI entries
-which are considered claimed <tref>WebID</tref>s at this point, since they have not been verified. The <tref>Verification Agent</tref> may verify as many or as few WebIDs it has time for. It may do it in parallel and asynchronously. However that is done, a claimed WebID can only be considered verified if the following steps have been accomplished successfully:</li>
+<li>The <tref>Guard</tref> then MUST ask the <tref>Verification Agent</tref> to verify that the WebIDs in the WebID Certificate do identify the agent who knows the given public key.</li>
+<li>The <tref>Verification Agent</tref> MUST extract the <tref>Public Key</tref> and all the URI entries contained in the <code>Subject Alternative Name</code> extension of the <tref>WebID Certificate</tref>.  
+A <tref>WebID Certificate</tref> MAY contain multiple URI entries which are considered <tref>Claimed WebID</tref>s at this point, since they have not been verified. 
+The <tref>Verification Agent</tref> may verify as many or as few WebIDs it has time for. 
+It may do it in parallel and asynchronously. 
+However that is done, a <tref>Claimed WebID</tref> can only be considered verified if the following steps have been accomplished successfully:</li>
 <ol>
-<li>If the <tref>WebID Verifier</tref> does not have an up to date version of the WebID profile in the cache, then it MUST dereference the WebID using the canonical method for dereferencing a URL of that scheme. For an <code>https://...</code> WebID this would be done using the [[!HTTP-TLS]] protocol. </li>
+<li>If the <tref>WebID Verifier</tref> does not have an up to date version of the WebID profile in the cache, then it MUST dereference the WebID using the canonical method for dereferencing a URL of that scheme. 
+For an <code>https://...</code> WebID this would be done using the [[!HTTP-TLS]] protocol. 
+</li>
 <li>The returned representation is then transformed into an RDF graph as specified in <a href="#processing-the-webid-profile">Processing the WebID Profile</a> </li>
-<li>That graph is then queried as explained in <a href="#querying-the-graph">Querying the Graph</a>. If the query succeeds, then that WebID is verified.
+<li>That graph is then queried as explained in <a href="#querying-the-graph">Querying the Graph</a>. 
+If the query is answered positively, then that WebID is verified.
 </li>
 </ol>
-<li>With the set of verified WebIDs 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 WebID 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>
+<li>With the set of verified WebIDs 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 WebID 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>
 <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>
 </ol>
 <ol>