--- a/spec/index-respec.html Wed Nov 30 14:49:30 2011 +0100
+++ b/spec/index-respec.html Sat Dec 10 21:29:33 2011 +0100
@@ -48,6 +48,10 @@
// extend the bibliography entries
berjon.biblio["RFC5246"] = "T. Dierks; E. Rescorla. <a href=\"http://tools.ietf.org/html/rfc5246\"><cite>The Transport Layer Security (TLS) Protocol Version 1.2</cite></a> August 2008. Internet RFC 5246. URL: <a href=\"http://tools.ietf.org/html/rfc5246\">http://tools.ietf.org/html/rfc5246</a> ";
berjon.biblio["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> ";
+ berjon.biblio["RDFA-CORE"] = "B. Adida, M. Birbeck, S. McCarron, I. Herman, <a href=\"http://www.w3.org/TR/2011/WD-rdfa-core-20110331/\"><cite>RDFa Core 1.1 - Syntax and processing rules for embedding RDF through attributes</cite></a> 31 March 2011. W3C Working Draft. URL: <a href=\"http://www.w3.org/TR/2011/WD-rdfa-core-20110331/\">http://www.w3.org/TR/2011/WD-rdfa-core-20110331/</a> ";
+ berjon.biblio["SOAP12-PART1"] = "M. Gudgin, M. Hadley, N. Mendelsohn, J. Moreau, H. F. Nielsen, A. Karmarkar, Y. Lafon, <a href=\"http://www.w3.org/TR/2007/REC-soap12-part1-20070427/\"><cite>SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)</cite></a> 27 April 2007. W3C Recommendation. URL: <a href=\"http://www.w3.org/TR/2007/REC-soap12-part1-20070427/\">http://www.w3.org/TR/2007/REC-soap12-part1-20070427/</a> ";
+ berjon.biblio["HTML5"] = "I. Hickson, <a href=\"http://www.w3.org/TR/2011/WD-html5-20110525/\"><cite>HTML5 - A vocabulary and associated APIs for HTML and XHTML</cite></a> 25 May 2011. W3C Working Draft. URL: <a href=\"http://www.w3.org/TR/2011/WD-html5-20110525/\">http://www.w3.org/TR/2011/WD-html5-20110525/</a> ";
+ berjon.biblio["Cert1"] = "H. Story, <a href=\"http://www.w3.org/ns/auth/cert#\"><cite>The Cert Ontology 1.0</cite></a> 13 November 2008. W3C Namespace Document. URL: <a href=\"http://www.w3.org/ns/auth/cert#\">http://www.w3.org/ns/auth/cert#</a> ";
// process the document before anything else is done
var refs = document.querySelectorAll('adef') ;
@@ -301,7 +305,7 @@
and RDF [[!RDF-PRIMER]] is necessary to understand how
to implement this specification. WebID uses a number of specific technologies
like HTTP over TLS [[!HTTP-TLS]], X.509 certificates [[!X509V3]],
-RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and XHTML+RDFa [[!XHTML-RDFA]].</p>
+RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and XHTML+RDFa [[!RDFA-CORE]].</p>
<p>A general <a href="#introduction">Introduction</a> is provided for all that
would like to understand why this specification is necessary to simplify usage
@@ -323,7 +327,7 @@
developers, and by other W3C groups and interested parties, and is
endorsed by the Director as a W3C Recommendation. It is a stable
document and may be used as reference material or cited from another
-document. W3C's role in making the Recommendation is to draw attention
+document. W3C's role in making the Recommendation is to draw attention
to the specification and to promote its widespread deployment. This
enhances the functionality and interoperability of the Web.</p> -->
@@ -409,7 +413,7 @@
<dd>Alice is an agent who owns a Server which runs a Service which Bob wishes to Access</dd>
<dt><tdef>Bob</tdef></dt>
-<dd>Bob is an agent who uses a <tref>Client</tref> to connect to <tref>Alice</tref>'s Service, and who is responsible for the private key the <tref>Client</tref> uses to authenticate to <tref>Service</tref>s.
+<dd>Bob is an agent who uses a <tref>Client</tref> to connect to <tref>Alice</tref>'s Service, and who is responsible for the private key the <tref>Client</tref> uses to authenticate to <tref>Service</tref>s.
If he notices the private key was compromised he needs to take action to disable the public key.
</dd>
<dt><tdef>Subject</tdef></dt>
@@ -437,12 +441,12 @@
Trust decisions on other attributes of the <tref>Subject</tref> published in the Certificate - such as his name - are traditionally based on the trust in the Agent that signed the Certificate - known as a <tref>Certificate Authority</tref>.
</dd>
<dt><tdef>Certificate</tdef><dt>
-<dd>A Certificate is a document that affirms statements about a <tref>Subject</tref> such as its <tref>public key</tref> and its name, and that is signed by a <tref>Certificate Authority</tref> using the private key that corresponds to the public key published in its certificate. The Certificate Authority's own Certificate is self signed. Certificates used by TLS are traditionally X509 [[!X509V3]] Certificates. </dd>
+<dd>A Certificate is a document that affirms statements about a <tref>Subject</tref> such as its <tref>public key</tref> and its name, and that is signed by a <tref>Certificate Authority</tref> using the private key that corresponds to the public key published in its certificate. The Certificate Authority's own Certificate is self signed. Certificates used by TLS are traditionally X509 [[!X509V3]] Certificates. </dd>
<dt><tdef>Certificate Authority</tdef> (<tdef>CA</tdef>)</dt>
<dd>
A Certificate Authority is a Subject that signs <tref>Certificates</tref>.
It is an Authority for what is written in the Certificate for any Agent that trusts it to be truthful in what it signs.
-Such agents use the knowledge of the CA's public key to verify the statements made by that CA in any of the Certificates it signed.
+Such agents use the knowledge of the CA's public key to verify the statements made by that CA in any of the Certificates it signed.
<tref>Service</tref>s usually identify themselves with Certificates signed by well known and widely deployed CAs available in all agents.
</dd>
<dt><tdef>TLS-Light Service</tdef></dt>
@@ -490,11 +494,11 @@
<dt><tdef>WebID Profile</tdef> or <tdef>Profile Page</tdef></dt>
<dd>
-A structured document asserting the relationship between the Subject (identified by his WebID) and his <tref>Public Key</tref>s using relationships as defined by the Resource Description Framework [[RDF-CONCEPTS]] and published at the URL location of the Subject's WebID.
+A structured document asserting the relationship between the Subject (identified by his WebID) and his <tref>Public Key</tref>s using relationships as defined by the Resource Description Framework [[RDF-CONCEPTS]] and published at the URL location of the Subject's WebID.
Dereferencing the <tref>WebID</tref> should return the Profile Document in one of a number of formats.
-The Server MUST publish the document in at least the XHTML+RDFa 1.1 [[!XHTML-RDFA]] serialization format or in RDF/XML [[!RDF-SYNTAX-GRAMMAR]].
-The document may be published in a number of other RDF serialization formats, such as N3 [[!N3]] or Turtle [[!TURTLE]].
-Any serialisation MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]].
+The Server MUST publish the document in at least the XHTML+RDFa 1.1 [[!RDFA-CORE]] serialization format or in RDF/XML [[!RDF-SYNTAX-GRAMMAR]].
+The document may be published in a number of other RDF serialization formats, such as Turtle [[!TURTLE]].
+Any serialisation MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[GRDDL-PRIMER]].
<p class="issue">Most profiles are currently written out in either of those formats. Whether or not XHTML+RDFa 1.1, both either serialization of RDF should be required serialization formats in the specification is currently under heavy debate and is open to change. </p>
</dd>
@@ -532,7 +536,7 @@
</tbody>
</table>
-<p>The ex: namespace is a URI that refers to Bob's profile, where Bob is an imaginary charcter well known in security circles.</p>
+<p>The ex: namespace is a URI that refers to Bob's profile, where Bob is an imaginary charcter well known in security circles.</p>
</section>
@@ -624,7 +628,7 @@
<section class='normative'>
<h1>Publishing the WebID Profile Document</h1>
-<p>The <tref>WebID Profile</tref> document MUST expose the relation between the <tref>WebID URI</tref> and the <tref>Identification Agent</tref>'s <tref>public key</tref>s using the <code>cert</code> ontologies, as well as the standard <code>xsd</code> datatypes.
+<p>The <tref>WebID Profile</tref> document MUST expose the relation between the <tref>WebID URI</tref> and the <tref>Identification Agent</tref>'s <tref>public key</tref>s using the <code>cert</code> ontologies, as well as the standard <code>xsd</code> datatypes.
The set of relations to be published at the <tref>WebID Profile</tref> document can be presented in a graphical notation as follows.</p>
<img alt="Web ID graph" width="90%" src="img/WebIdGraph.jpg"/>
<p>The document can publish many more relations than are of interest to the WebID protocol, as shown in the above graph by the grayed out relations.
@@ -636,7 +640,7 @@
Yet for reasons of interoperabity is has been decided that the document MUST be published at least in one of RDFa [XHTML-RDFA] or RDF/XML [RDF-SYNTAX-GRAMMAR].
HTTP Content Negotiation [SWBP-VOCAB-PUB] can be employed to aid in publication and discovery of multiple distinct serialisations of the same graph at the same URL. </p>
<p>
-Irrespective of whether content negotiation can or not be employed, if an HTML representation of the WebID profile is published, it is suggested that the provider uses the HTML <code><link></code> element to allow discovery of the various alternate representations of the graph which may be available:
+Irrespective of whether content negotiation can or not be employed, if an HTML [[!HTML5]] representation of the WebID profile is published, it is suggested that the provider uses the HTML [[!HTML5]] <code><link></code> element to allow discovery of the various alternate representations of the graph which may be available:
</p>
<pre class="example">
@@ -647,7 +651,7 @@
...
</head> ...
</pre>
-<p>It is particularly useful to have one of the representations be in HTML or
+<p>It is particularly useful to have one of the representations be in HTML [[!HTML5]] or
XHTML even if it is not marked up in RDFa as this allows people using a
web browser to understand what the information at that URI represents.</p>
<section class='normative'>
@@ -681,12 +685,12 @@
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" version="XHTML+RDFa 1.0" dir="ltr"
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" version="XHTML+RDFa 1.0"
xmlns:cert="http://www.w3.org/ns/auth/cert#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#">
<head>
- <title>Welcome to Bob's Home Page</title>
+ <title>Welcome to Bob's Home Page</title>
</head>
<body>
<!-- WebID HTML snippet. The xmlns declarations above can be moved into the div below if needed-->
@@ -781,9 +785,9 @@
<h1>Authentication Sequence</h1>
<p>In order to give the full context of a <tref>Client</tref> interaction with a <tref>Server</tref> we will illustrate the protocol with the following sequence diagram.
- <tref>Bob</tref> initiates a connection to <tref>Alice</tref>'s server via a TLS enabled protocol such as https in order to access a Protected Resource or a Protected Service.
+ <tref>Bob</tref> initiates a connection to <tref>Alice</tref>'s server via a TLS enabled protocol such as https in order to access a Protected Resource or a Protected Service.
The Protected Resource MUST be served over a <tref>TLS-Light Service</tref>, that will not do full <tref>CA</tref> authentication of <tref>Client</tref> <tref>Certificate</tref>s it receives.
-The Protected Resource may be a document served over https, but it could also be a SOAP service, or some other resource.
+The Protected Resource may be a document served over https, but it could also be a SOAP [[SOAP12-PART1]] service, or some other resource.
This resource is protected by a Guard, which uses a <tref>WebID Verifier</tref> to verify the non Certified WebIds found in the certificate.
Once the verification succeeds the Guard checks to see if the Agent identified by the <tref>WebID</tref> is allowed access to the resource, by using trusted information from the Web and access control rules.
</p>
@@ -791,7 +795,7 @@
<img width="90%" src="img/WebIDSequence-friendly.jpg">
<p>The steps in detail are as follows:</p>
<ol>
-<li><tref>Bob</tref>'s <tref>Client</tref> MUST open a TLS [[!RFC5246]] connection with the server which authenticates itself using well known TLS mechanisms. This MAY be done as the first part of an HTTPS connection [[!HTTP-TLS]].</li>
+<li><tref>Bob</tref>'s <tref>Client</tref> MUST open a TLS [[!RFC5246]] connection with the server which authenticates itself using well known TLS mechanisms. This MAY be done as the first part of an HTTPS connection [[!HTTP-TLS]].</li>
<li>Once the Transport Layer Security [TLS] has been set up, the application protocol exchange can start. If the protocol is HTTP then the client can request an HTTP GET, PUT, POST, DELETE, ... action on a resource as detailed by [[!HTTP11]]. The <tref>Guard</tref> can then intercept that request and by checking some access control rules determine if the client needs authentication. We will consider the case here where the client does need to be authenticated.</li>
<li>The Guard MUST requests the client to authenticate itself using public key cryptography by signing a token with its private key and have the Client send its Certificate. This has been carefully defined in the TLS protocol and can be summarised by the following steps:
<ol>
@@ -826,7 +830,7 @@
<h2>Initiating a TLS Connection</h2>
<p>Standard SSLv3 and TLSv1 and upwards can be used to establish the connection between
-the Client and the TLS Agent listening on the Service's port. </p>
+the Client and the TLS Agent listening on the Service's port. </p>
<p class="note">Many servers allow a simple form of TLS client side authentication to be setup when configuring a <tref>TLS Agent</tref>: they permit the agent to be authenticated in WANT or NEED mode.
If the client sends a certificate, then neither of these have an impact on the <tref>WebID Verification</tref> steps (4) and (5).
Nevertheless, from a user interaction perspective both of these are problematic as they either force (NEED) or ask the user to authenticate himself even if the resource he wishes to interact with is public and requires no authentication.
@@ -851,7 +855,7 @@
<section class='normative'>
<h2>Requesting the Client Certificate</h2>
-<p>TLS allows the server to request a Certificate from the Client using the <code>CertificateRequest</code> message [section 7.4.4] of TLS v1.1 [[!RFC5246]]. Since WebID TLS authentication does not rely on CA's signing the certificate to verify the WebID Claims made therein, the Server does not need to restrict the certificate it receives by the CA's they were signed by. It can therefore leave the <code>certificate_authorities</code> field blank in the request. </p>
+<p>TLS allows the server to request a Certificate from the Client using the <code>CertificateRequest</code> message [section 7.4.4] of TLS v1.1 [[!RFC5246]]. Since WebID TLS authentication does not rely on CA's signing the certificate to verify the WebID Claims made therein, the Server does not need to restrict the certificate it receives by the CA's they were signed by. It can therefore leave the <code>certificate_authorities</code> field blank in the request. </p>
<p class="note">From our experience leaving the certificate_authorities field empty leads to the correct behavior on all browsers and all TLS versions.</p>
<p class="note">A security issue with TLS renegotiation was discovered in 2009, and an IETF fix was proposed in [[!RFC5746]] which is widely implemented.</p>
<p>If the Client does not send a certificate, because either it does not have one or it does not wish to send one, other authentication procedures can be pursued at the application layer with protocols such as OpenID, OAuth, BrowserID, etc... </p>
@@ -864,7 +868,7 @@
</section>
<section class='normative'>
<h2>Verifiying the WebIDs</h2>
-<p>The <tref>Verification Agent</tref> is given a list of WebIDs associated with a public key. It needs to verify that the agent identified by that WebID is indeed the agent that controls the private key of the given public key. It does this by looking up the definition of the WebID. A WebID is a URI, and it's meaning can be had by dereferencing it using the protocol indicated in its scheme. </p>
+<p>The <tref>Verification Agent</tref> is given a list of WebIDs associated with a public key. It needs to verify that the agent identified by that WebID is indeed the agent that controls the private key of the given public key. It does this by looking up the definition of the WebID. A WebID is a URI, and it's meaning can be had by dereferencing it using the protocol indicated in its scheme. </p>
<p>If we first consider WebIDs with fragment identifiers, we can explain the logic of this as follows. As is explained in the RFC defining URIs [[!RFC3986]]
<blockquote>
The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information.
@@ -876,14 +880,14 @@
This resource will describe the referent of the WebID in some way.
If it says that the referent of the WebID is the agent that controls the private key of the given public key, then this is a definite description that can be considered to be a definition of the WebID: it gives its meaning.
</p>
-<p>The trust that can be had in that statement is therefore the trust that one can have in one's having received the correct representation of the document that defined that WebID.
+<p>The trust that can be had in that statement is therefore the trust that one can have in one's having received the correct representation of the document that defined that WebID.
An https WebID will therefore be a lot more trustworthy than an https WebID by a factor of the likelyhood of man in the middle attacks.</p>
<p>Once that is proven then the trust one can have in the agent at the end of the TLS connection being the referent of the WebID is related to the trust one has in the cryptography, and the likelyhood that the private key could have been stolen.</p>
<p class="issue">Add explanation for URI with redirect.</p>
<section class='normative'>
<h2>Processing the WebID Profile</h2>
-<p>So the Verification Agent needs to fetch the document, if it does not have a valid one in cache. <tref>Verification Agent</tref> MUST be able to process documents in RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and RDFa in XHTML [[!XHTML-RDFA]]. The result of this processing should be a graph of RDF relations that is queryable, as explained in the next section.</p>
+<p>So the Verification Agent needs to fetch the document, if it does not have a valid one in cache. <tref>Verification Agent</tref> MUST be able to process documents in RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and RDFa in XHTML [[!RDFA-CORE]]. The result of this processing should be a graph of RDF relations that is queryable, as explained in the next section.</p>
<p class="note">
It is suggested that the <tref>Verification Agent</tref> should set the Accept-Header to request <code>application/rdf+xml</code> with a higher priority than <code>text/html</code> and <code>application/xhtml+xml</code>. The reason is that it is quite likely that many sites will produce non marked up html and leave the graph to the pure rdf formats.
</p>
@@ -923,7 +927,7 @@
</tbody>
</table>
-<p>Assuming that we received Bob's key whose modulus starts with <code>cb24ed85d64d794b6...</code> and whose exponent is <code>65537</code> then the following query should be used:
+<p>Assuming that we received Bob's key whose modulus starts with <code>cb24ed85d64d794b6...</code> and whose exponent is <code>65537</code> then the following query should be used:
</p>
<pre class='example' style="word-wrap: break-word; white-space: pre-wrap;">
PREFIX : <http://www.w3.org/ns/auth/cert#>
@@ -946,10 +950,10 @@
<p>The Authorization step may be as simple as just allowing everybody read access. The authentication phase may then just have been useful in order to gain some extra information from the <tref>WebID Profile</tref> in order to personalise a site.</p>
<p>Once the <tref>Guard</tref> has a WebID he can do a lookup in a database to see if the agent is allowed the required access to the given resource.
-Up to this point we are not much more advanced that with a user name and password, except that the user did not have to create an account on Alice's server to identify himself and that the server has some claimed attributes to personalise the site for the requestor.
+Up to this point we are not much more advanced that with a user name and password, except that the user did not have to create an account on Alice's server to identify himself and that the server has some claimed attributes to personalise the site for the requestor.
But the interesting thing about such a WebID is that because it is a global linkable URI, one can build webs of trust that can be crawled the same way the web can be crawled: by following links from one document to another.
-It is therfore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friend and those friends friends (FOAF), stated by them at their domains.
-It is even be possible to allow remote agents to define their own access control rules for parts of the machine's namespace.
+It is therfore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friend and those friends friends (FOAF), stated by them at their domains.
+It is even be possible to allow remote agents to define their own access control rules for parts of the machine's namespace.
There are too many possibilities to list them all here.
</p>