--- a/spec/identity-respec.html Tue Oct 15 18:12:59 2013 +0200
+++ b/spec/identity-respec.html Wed Oct 16 18:52:17 2013 +0200
@@ -536,14 +536,13 @@
<section class="informative">
<h1>Privacy</h1>
<p>
-A WebID Profile is a public document that may contain more or less personal information about the agent identified by the WebID.
-Some agents may want to reveal a lot more information publically about themselves than others.
-RDF allows each agent to choose how much information they wish to make publically available.
+A WebID Profile is a public document that may contain public as well personal information about the agent identified by the WebID.
+As some agents may not want to reveal a lot of information about themselves, RDF and Linked Data principles allows them to choose how much information they wish to make publicly available.
+This can be achieved by separating parts of the profile information into separate documents, each protected by access control policies.
</p>
<p>
-Some agents may be happy to publish more information about themselves, but only to a select group of trusted agents.
-This can be achieved by separating parts of the profile information into separate documents, each protected by access control policies.
-In the following example, Bob is limiting access to his list of friends, by placing all foaf:knows relations into a separate document.
+On the other hand, some agents may want to publish more information about themselves, but only to a select group of trusted agents.
+In the following example, Bob is limiting access to his list of friends, by placing all <em>foaf:knows</em> relations into a separate document.
</p>
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
@@ -560,7 +559,7 @@
foaf:img <https://bob.example.org/picture.jpg> .
</pre>
-<p>Where https://bob.example.org/friends is a reference to an ACL protected document containing:</p>
+<p>Where https://bob.example.org/friends is a reference to an Access Control List (ACL) protected document containing:</p>
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@@ -574,7 +573,7 @@
foaf:knows <https://example.com/people/Mary/card#me> .
</pre>
-<p>Having the following corresponding ACL rule, expressed using the <a href="http://www.w3.org/wiki/WebAccessControl">WebAccessControl</a> ontology:</p>
+<p>and having the following corresponding ACL rule, expressed using the <a href="http://www.w3.org/wiki/WebAccessControl">WebAccessControl</a> ontology:</p>
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@@ -591,16 +590,16 @@
<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.
+to subvert the meaning of the WebID, and to make agents following links within the <tref>WebID Profile</tref> come to different conclusions from those intended by profile owners.
</p>
<p>
-The standard way of overcoming such attacks is to build on the HTTPS [[!HTTP-TLS]] stack of cryptographic security protocols.
-HTTPS servers are identified by a certificate signed either by a well known Certificate Authority or whose public key is listed in the DNSSEC as specified by the DANE protocol [[!DANE]] or both.
+The standard way of overcoming such attacks is to rely on the cryptographic security protocols within the HTTPS [[!HTTP-TLS]] stack.
+HTTPS servers are identified by a certificate either signed by a well known Certification Authority or whose public key is listed in the DNSSEC as specified by the DANE protocol [[!DANE]], or both.
This makes it much more difficult to set up a fake server by DNS Poisoning attacks.
-Resources served over HTTPS are furthermore signed and encrypted removing all the simple man in the middle attacks.
+Resources served over HTTPS are furthermore signed and encrypted removing all the simple man-in-the-middle attacks.
</p>
-<p>Applying the above security measures does not remove the burden from server administrators to practice good security hygene, to avoid direct infiltration of their servers by enemy code.
-Similarly clients that fetch documents on the web need to make sure their work environment is not infected by virus or trojans.
+<p>Applying the above security measure does not remove the burden from server administrators to take the appropriate security measures, in order to avoid compromising their servers.
+Similarly, clients that fetch documents on the web also need to make sure their work environment has not been compromised.
</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>
--- a/spec/tls-respec.html Tue Oct 15 18:12:59 2013 +0200
+++ b/spec/tls-respec.html Wed Oct 16 18:52:17 2013 +0200
@@ -963,44 +963,44 @@
<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.
+ In an WebID authentication process, three actors 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.
+ During authentication, the <tref>Subject</tref> authenticating to a server must reveal one of his identies.
+ As a consequence, information that is associated with that identity, found at the <tref>WebID Profile</tref>, will be tied to behavioral information that can be gathered by the site he is logging into.
+ Even though access to profile information can be restricted through access control policies (based on ontologies such as <a href="http://www.w3.org/wiki/WebAccessControl">Web Access Control</a>), by aggregating user data from multiple servers that exchange information about users, attackers could in theory be able to build a complete profile of a given user.
</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.
+ It is therefore important that the <tref>Subject</tref> understands the privacy policies of the site to which he authenticates in order to 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 agents 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>.
+ Further flexibility may be offered to the authenticating <tref>Subject</tref> as to adapt his privacy policies to a site, allowing the user to decide about the group of agents with whom he will share the information he generates.
</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.
+ To avoid potential deadlock 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>Even though a <tref>WebID Profile</tref> document MUST be publicly accessible, the <tref>WebID Profile</tref> can be split among multiple resources that are linked and protected by access control lists (as explained in the privacy section of the WebID specification [[!WebID]]), in order to provide limited access to private 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.
+ As a consequence of dereferencing the <tref>WebID Profile</tref> during authentication, identity providers such as the server hosting the profile document are able to track the IP addresses of incoming requests for the user's profile document, and potentially match them to a list of known servers and services.
+ In other words, unless the user hosts her profile on a private server, the identity provider will be able to track the user across each server she authenticates to, building a detailed log of all the servers inquiring about the user's profile.
+ For servers administered by another entity, a <tref>Subject</tref> should in any case act in such a way that she behaves in accordance with the requirements of the organization 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.
+ A server must make sure that information is served only to Agents that are allowed access to that information - public information should be made available to anyone, and non public information be only made available to those that are 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>As explained in the previous section, the <tref>WebID Verifier</tref> MUST NOT authenticate when fetching a WebID profile, as this leads to deadlock situations. </p>
</p>
</section>
</section>
@@ -1010,17 +1010,18 @@
<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.
+to subvert the meaning of the WebID, and to make agents following links within the <tref>WebID Profile</tref> come to different conclusions from those intended by profile owners.
</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 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.
-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.
+<p>When authenticating clients identified by an <code>http://</code> (as opposed to <code>https://</code>) WebID, the server to which the client is authenticating should take into account the potential man-in-the-middle attack or DNS poisoning attacks that may take place when fetching a non secure resource on the Web.
+The server to which the client is authenticating should take these attacks into account when deciding what level of service to provide for the user, and also 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 additional channels.
+</p>
+<p>For more sensitive transactions, a server authenticating <code>https://</code> WebIDs may want to make sure that the <tref>WebID Profile</tref> information it obtains is recent, 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 one or more of its private keys were compromised.</p>
+<p>A server to which the client is authenticating must remember that the contents of a <tref>WebID Profile</tref> is only a self assertion by the <tref>WebID</tref> owner.
+In other words, the server can decide on the authenticity of 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, leading to a Web of trust.
+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 publicly 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>