--- 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>