--- a/spec/tls-respec.html	Mon Oct 14 12:04:50 2013 +0200
+++ b/spec/tls-respec.html	Tue Oct 15 10:32:59 2013 +0200
@@ -940,7 +940,7 @@
 <h2>Verifying the WebID claim without SPARQL</h2>
 <p>If the RDF library does datatype normalization 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 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>
+<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 its <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='informative'>
@@ -967,7 +967,7 @@
 <p>When authenticating clients identified by an <code>http</code> ( as opposed to <code>https</code>) WebID, the authenticating server needs to take into account the potential man in the middle attack or DNS poisoning attacks that it is open to when fetching a non secure resource on the web. 
 The authenticating server should take these attacks into account when deciding what level of service to provide the user and what type of information to allow him access to. 
 If such a user wants to access sensitive data or enter a serious transaction it may be important to verify his authenticity using other channels.</p>
-<p>A server authenticating <code>https</code> WebIDs may for more important transaction want to make sure it's version of the <tref>WebID Profile</tref> is a recent version in order to be able to exclude the possibility that the user disabled that certificate by removing its public key from the list of <code>cert:key</code>s listed in the <tref>WebID Profile</tref>. A user may do that on discovering that it's private key was compromised. </p>
+<p>A server authenticating <code>https</code> WebIDs may for more important transaction want to make sure its version of the <tref>WebID Profile</tref> is a recent version in order to be able to exclude the possibility that the user disabled that certificate by removing its public key from the list of <code>cert:key</code>s listed in the <tref>WebID Profile</tref>. A user may do that on discovering that its private key was compromised. </p>
 <p>An authenticating server MUST take care not to assume that anything else in the <tref>WebID Profile</tref> is other than a self assertion by the <tref>WebID</tref> owner. 
 That is the server can use that information when communicating with the referent of the WebID itself, but it must take care not to assume that other agents on the web will agree with those statements.  
 If other agents do build up relations to that <tref>WebID</tref> then depending on the nature of those relations one may conclude to a certain overlapping of points of views.