--- a/spec/identity-respec.html Sun Oct 13 19:58:53 2013 +0200
+++ b/spec/identity-respec.html Sun Oct 13 23:19:40 2013 +0200
@@ -175,6 +175,11 @@
var respecConfig = {
+ localBiblio: {
+ RFC5746: "E. Rescorla, M. Ray, S. Dispensa, N. Oskov, <a href='http://tools.ietf.org/html/rfc5746'><cite>Transport Layer Security (TLS) Renegotiation Indication Extension</cite></a> February 2010. Internet RFC 5246. URL: <a href=\"http://tools.ietf.org/html/rfc5746\">http://tools.ietf.org/html/rfc5746</a>",
+ WEBID: "Henry Story, Andrei Sambra, Stéphane Corlosquet, <a href='https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html'><cite>WebID 1.0: Web Identity and Discovery.</cite></a>",
+ DANE: "P. Hoffman, J. Schlyter, <a href='http://tools.ietf.org/html/rfc6698'>RFC6698: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</a>"
+ },
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
// embed RDFa data in the output
doRDFa: true,
@@ -530,7 +535,16 @@
<section class="informative">
<h1>Privacy</h1>
-<p>A WebID Profile document need not contain only public resources. A possible way of protecting its contents 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.</p>
+<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.
+</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.
+</p>
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@@ -574,7 +588,22 @@
<section class="informative">
<h1>Security Considerations</h1>
-Given that this section is non-normative, and due to the fact that additional attacks may be discovered at a later time, a collection of security considerations has been made available on the <a href="http://www.w3.org/2005/Incubator/webid/wiki/Identity_Security">WebID Wiki</a>.
+<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>
+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.
+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.
+</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>
+<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>
Binary file spec/img/keygen-sequence.graffle/data.plist has changed
--- a/spec/tls-respec.html Sun Oct 13 19:58:53 2013 +0200
+++ b/spec/tls-respec.html Sun Oct 13 23:19:40 2013 +0200
@@ -162,8 +162,9 @@
var respecConfig = {
localBiblio: {
- RFC5746: "E. Rescorla, M. Ray, S. Dispensa, N. Oskov, <a href=\"http://tools.ietf.org/html/rfc5746\"><cite>Transport Layer Security (TLS) Renegotiation Indication Extension</cite></a> February 2010. Internet RFC 5246. URL: <a href=\"http://tools.ietf.org/html/rfc5746\">http://tools.ietf.org/html/rfc5746</a>",
- WEBID: "Andrei Sambra, Stéphane Corlosquet. <a href='https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html'><cite>WebID 1.0: Web Identity and Discovery.</cite></a>",
+ RFC5746: "E. Rescorla, M. Ray, S. Dispensa, N. Oskov, <a href='http://tools.ietf.org/html/rfc5746'><cite>Transport Layer Security (TLS) Renegotiation Indication Extension</cite></a> February 2010. Internet RFC 5246. URL: <a href=\"http://tools.ietf.org/html/rfc5746\">http://tools.ietf.org/html/rfc5746</a>",
+ WEBID: "Henry Story, Andrei Sambra, Stéphane Corlosquet, <a href='https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html'><cite>WebID 1.0: Web Identity and Discovery.</cite></a>",
+ DANE: "P. Hoffman, J. Schlyter, <a href='http://tools.ietf.org/html/rfc6698'>RFC6698: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</a>"
},
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
// embed RDFa data in the output