--- a/spec/index-respec.html	Tue Dec 06 22:40:58 2011 +0100
+++ b/spec/index-respec.html	Thu Dec 08 13:09:38 2011 +0100
@@ -373,7 +373,7 @@
 <dt><tdef>Subject</tdef></dt>
 <dd>The Subject is the Agent that is identified by the <tref>WebID</tref>.
 When used legally it is the Subject who wishes to authenticate to a <tref>Service</tref>.
-We will name our princiap Subject <tref>Bob</tref> throughout the text, when this helps lisibility.
+We will name him  <tref>Bob</tref> throughout the text when this helps lisibility.
 The Subject is distinct from the <tref>Client</tref> which is used to connect to the <tref>Server</tref>.
 </dd>
 <dt><tdef>Client</tdef></dt>
@@ -879,7 +879,8 @@
 <p>
 To check a WebID claim one has to find if the graph returned by the profile  relates the <tref>WebID</tref> to the  <tref>Certificate</tref> <tref>Public Key</tref> with the <code>cert:key</code> relation. In other words one has to check if those statements are present in the graph.</p>
 
-
+<section class="normative">
+<h2>Verifying the WebID Claim with SPARQL</h2>
 <p>Testing for patterns in graphs is what the SPARQL query language is designed to do [[!RDF-SPARQL-QUERY]]. We will first look at how to use this as it is also the simplest method, and then what some other programmatic options may be.</p>
 <p>Below is the SPARQL Query Template which should be used for an RSA public key. It contains three variables <code>?webid</code>, <code>?mod</code> and <code>?exp</code> that need to be replaced by the appropriate values:</p>
 <pre style="word-wrap: break-word; white-space: pre-wrap;">
@@ -902,7 +903,7 @@
 </thead>
 <tbody>
 <tr><td><code>?webid</code></td><td>should be replaced by the WebID Resource. In the SPARQL notation that is the URL string would be placed between <code>&lt;...&gt;</code> in the position of the <code>?webid</code> variable. </td></tr>
-<tr><td><code>?mod</code></td><td>should be replaced by the modulus written as a xsd:hexBinary as specified by the <a href="http://www.w3.org/ns/auth/cert#modulus">cert:modulus</a> relation. All leading double 0 bytes (written  "00" in hexadecimal) should be removed. The resulting hexadecmial should then be placed in the space of the XXX in <code>"XXX"^^xsd:hexBinary</code> </td></tr>
+<tr><td><code>?mod</code></td><td>should be replaced by the modulus written as a xsd:hexBinary as specified by the <a href="http://www.w3.org/ns/auth/cert#modulus">cert:modulus</a> relation. All leading double 0 bytes (written  "00" in hexadecimal) should be removed. The resulting hexadecimal should then be placed in the space of the XXX in <code>"XXX"^^xsd:hexBinary</code> </td></tr>
 <tr><td><code>?exp</code></td><td>should be replaced by the public exponent written as an xsd:integer typed literal. In SPARQL as in Turtle notation this can just be written directly as an integer.</td></tr>
 </tbody>
 </table>
@@ -919,10 +920,15 @@
    ] .
 }
 </pre>
-<p>An ASK query simply returns true or false. If it returns true, then the key was found in the graph with the proper relation and the claim has been verified.</p>
-<p class="issue"> The public key could be a DSA key. We need to add an ontology
-for DSA too.</p>
-
+<p>An ASK query simply returns true or false. If it returns true, then the key was found in the graph with the proper relation and the claim is verified.</p>
+<p>In order to allow the class of queries defined by the template above to return true when asked of graphs where the hexBinary or the exponent contains whitespace characters in initial and final position, the query engine MUST support the D-entailment regime for <code>xsd:hexBinary</code> and <code>xsd:integer</code> as specified in <a href="http://www.w3.org/TR/sparql11-entailment/#DEntRegime">SPARQL 1.1 Entailment Regimes</a>.</p>
+<p>For verifiers that do not have access to a SPARQL query engine but that do have access programmatically to a triple store, it is relatively easy to emulate the above SPARQL query programmatically. There are a number of ways of doing this, some more efficient than others.<p>
+</section>
+<section class="normative">
+<h2>Verifying the WebID claim without SPARQL</h2>
+<p>If the triple store does dataype normalisation of all literals before loading them, then the most efficient way to execute this would be to start by searching for all triples whose subjects have relation <code>cert:modulus</code> to the literal which in our example was <code>"cb24ed..."^^xsd:hexBinary</code>. One would then iterate through all the subjects of the relations that satisfied that condition, which would most likely never number more than one, and from there filter out all those that were the object of the <code>cert:modulus</code> relation of the <tref>WebID</tref> - in the example <code>bob:me</code>. Finally one would verify that one of the keys that had satisfied those relations also had the <code>cert:exponent</code> relation to the number which in the example above is <code>"65537"^^xsd:integer</code>.  
+</p>
+<p>For triples stores that do not normalise literals on loading a graph, the normalizatino 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 normalised 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'>