--- a/spec/tls-respec.html	Mon Oct 14 12:04:39 2013 +0200
+++ b/spec/tls-respec.html	Mon Oct 14 12:04:50 2013 +0200
@@ -433,7 +433,7 @@
 </dd>
 
 <dt><tdef>Guard</tdef><dt>
-<dd>A Guard is an agent, usually on the <tref>Server</tref> that can look at a request from the <tref>Client</tref> and decide if it needs to be authorized by looking at the access control rules for that resource. 
+<dd>A Guard is an agent, usually on the <tref>Server</tref> that can look at a request from the <tref>Client</tref> and decide if it needs to be authorized by looking at the access control rules for that resource ( using the <a href="http://www.w3.org/wiki/WebAccessControl">Web Access Control</a> ontology perhaps )
 If the request requires authorization, the Guard can first demand authentication of the <tref>Client</tref> and use the <tref>WebID Verifier</tref> to check any claimed identies that would allow it to come to an authorization decision.
 Finally the Guard can grant or deny access according to how the verfied identities satisfy the Access Control Rules. 
 </dd>
@@ -958,10 +958,26 @@
 </section>
 
 <section class="informative">
-    <h2>Security Model</h2>
-    <p class="issue">this is a section that can look at different security issues such as
-    possible attack scenarios.
-    </p>
+    <h2>Security considerations</h2>
+ <p>A <tref>WebID</tref> identifies an agent via a description found in the associated <tref>WebID Profile</tref> document.
+An agent that wishes to know what a WebID refers to, must rely on the description found in the WebID Profile.
+An attack on the relation between the <tref>WebID</tref> and the <tref>WebID Profile</tref> can thus be used
+to subvert the meaning of the WebID, and so make agents following links on the Linked Data web come to conclusions different from that intended by the authors of those links.
+</p>
+<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>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.
+The position of the WebID in the global linked Data space may make a very big difference as to how much trust the authenticating server puts in the veracity of those relations.
+The publication of a profile on a publically listed company's web site may make the information legally binding and the legal framework may create a stronger space in which those statements can be accepted.
+This details of this trust reasoning goes way beyond what can be explored by the WebID authentication protocol.
+</p>
+<p>
+As security is constantly being challenged by new attacks, to which new responses are found, a collection of security considerations will be made available on the <a href="http://www.w3.org/2005/Incubator/webid/wiki/Identity_Security">WebID Wiki</a>.
+</p>
 </section>
 
 <section class='appendix informative' id="history">
@@ -1001,7 +1017,8 @@
 </p>
 </section>
 
-<section class='informative' id="acknowledgements">
+<section class='informative' id="acknowledgements">?
+
 <h1>Acknowledgments</h1>
 
 <p>The following people have been instrumental in providing thoughts, feedback,