--- a/spec/tls-respec.html	Tue Oct 15 10:32:59 2013 +0200
+++ b/spec/tls-respec.html	Tue Oct 15 14:36:44 2013 +0200
@@ -438,6 +438,10 @@
 Finally the Guard can grant or deny access according to how the verfied identities satisfy the Access Control Rules. 
 </dd>
 
+<dt><tdef>WebID Verifier</tdef><dt>
+<dd>A WebID Verifier is an agent trusted by the <tref>Server</tref> to verify that the <tref>Subject</tref> identified by the <tref>WebID</tref> is the one that knows the private key of the given public key. The Verifier uses the procedure determined in this protocol to do the verification. 
+</dd>
+
 <dt><tdef>WebID Claim</tdef> or <tdef>Claimed WebID</tdef></dt>
 <dd>A <tref>WebID Certificate</tref> can be thought of as 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. 
@@ -956,6 +960,50 @@
 </section>
 </section>
 </section>
+<section class="informative">
+    <h2>Privacy considerations</h2> 
+<p>
+  In an WebID authentication process three agents are involved: The authenticating <tref>Subject</tref>, the server he is authenticating to, and the server serving the <tref>WebID Profile</tref>. Different privacy considerations apply to each one of these actors.
+</p>
+    <section class="informative">
+    <h3>The Authenticating Subject</h3>
+<p>
+  The <tref>Subject</tref> authenticating to a server will on authentication reveal one of his identies and thereby allow information that is associated with that identity found at the <tref>WebID Profile</tref> to be tied to behavioral information that can be gathered by the site he is logging into, which can potentially be tied to information that site exchanges with other sites. 
+</p>
+<p>
+  It is therefore important that the <tref>Subject</tref> understand the privacy policies of the site authenticated to and choose the appropriate identity to use for that site. 
+</p>
+<p>
+  The development of a limited number of easy to understand and machine readable privacy policies, would greatly help users make informed decisions in this space.
+  Further flexibility may be offered the authenticating <tref>Subject</tref> to adapt his privacy policies to a site, allowing the user to decide what group of users the information he generates there can be shared with. 
+  This could be done using the <a href="http://www.w3.org/wiki/WebAccessControl">Web Access Control Ontology</a>.
+</p>
+   </section>
+   <section class="informative">
+   <h3>Privacy considerations for the WebID Profile Server</h3>
+   <p>
+   To avoid potential dealock problems, where one server needs to authenticate into a second server that itself requires authentication, etc... , <tref>WebID Profile</tref>'s MUST be public. 
+ It follows that WebID Authenticating servers MUST not authenticate when fetching a <tref>WebID Profile</tref>.
+   </p>
+   <p>Even though the Profile MUST be public, and as explained in the WebId specification's [[!WebID]] privacy section, <tref>WebID Profiles</tref> can be split among a number of different linked but access controlled resources to give limited access to confidential information. Information the user wishes to protect should be placed in those resources and <a href="http://www.w3.org/wiki/WebAccessControl">Access Controlled</a>.
+   </p>
+   <p>
+     Even though the <tref>WebID Verifier</tref> MUST NOT authenticate when fetching a WebID Profile, the ip address of the requesting server could still be used by the WebID Profile server to guess that the <tref>Subject</tref>  may be authenticating to that server - though that server may be fetching that profile for a number of other reasons, such as following links on the web.
+   This should not cause any privacy issues for profiles served by the <tref>Subject</tref>'s personal server, since she herself knows where she is authenticating to. 
+   She may in fact use this as a way to log the activity of referencing her WebID across the web.
+   For servers administered by another entity, a <tref>Subject</tref> should in any case act in such a way that she behave in accordance with the requirements of the organisation providing the identity.
+   </p>
+   </section>
+   <section class="informative">
+   <h3>Privacy considerations for the authenticating Server</h3>
+   <p>
+ Servers identify themselves in any transaction, and even more so when the transactions are done over HTTPS.
+ A server must make sure that information is served only to Agents that are allowed access to that information: that public information be made available to anyone, and that non public information be only made available to those allowed access.
+   </p>
+   <p>As explained in the previous section, the <tref>WebID Verifier</tref> MUST NOT authenticate when fetching a WebID profile, as this risks creating deadlock situations. </p>
+  </p>
+   </section>
+</section>
 
 <section class="informative">
     <h2>Security considerations</h2>