--- a/spec/index-respec.html Mon Jan 09 15:56:41 2012 +0100
+++ b/spec/index-respec.html Mon Jan 09 17:36:48 2012 +0100
@@ -444,7 +444,7 @@
</dd>
<dt><tdef>WebID</tdef></dt>
-<dd>A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions. The WebID should be a URI which when dereferenced returns a representation whose description uniquely identifies the Agent as the controller of a public key. In our example the WebID refers to Bob. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in the document.</dd>
+<dd>A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions. The WebID should be a URI which when dereferenced returns a representation whose description uniquely identifies the Agent who is the controller of a public key. In our example the WebID refers to <tref>Bob</tref>. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in this document.</dd>
</dd>
<dt><tdef>Public Key</tdef></dt>
@@ -609,7 +609,7 @@
Yet for reasons of interoperability 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 cannot 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:
</p>
<pre class="example">
@@ -695,7 +695,7 @@
<p>If a WebID provider would rather prefer not to mark up his data in RDFa, but
just provide a human readable format for users and have the RDF graph appear
in a machine readable format such as RDF/XML then he MAY publish the link from
-the HTML to a machine readable format (it this is available at a dedicated URI)
+the HTML to a machine readable format (if this is available at a dedicated URI)
as follows:</p>
<p class="example">
<pre>
@@ -778,7 +778,7 @@
<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>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>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 authorization and hence 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>
<li>The guard requests of the TLS agent that it make a Certificate Request to the client. The TLS layer does this. Because the WebID protocol does not rely on Certificate Authorities to verify the contents of the <tref>Certificate</tref>, the <tref>TLS Agent</tref> can ask for any Certificate from the Client. More details in <a href="#requesting-the-client-certificate">Requesting the Client Certificate</a></li>
@@ -789,9 +789,9 @@
</li>
<li>The <tref>Guard</tref> then MUST ask the <tref>Verification Agent</tref> to verify that the WebIDs do identify the agent who knows the given public key.</li>
<li>The WebID is verified by looking up the definition of the URL at its canonical location. This can be done by dereferencing it. The <tref>Verification Agent</tref> MUST extract the <tref>public key</tref> and all the URI entries contained in the <code>Subject Alternative Name</code> extension of the <tref>WebID Certificate</tref>. A <tref>WebID Certificate</tref> MAY contain multiple URI entries
-which are considered claimed <tref>WebID</tref>s at this point, since they have not been verified. The <tref>Verification Agent</tref> may verify as many or as few WebIDs it has time for. It may do it in parallel and asynchronously. However that is done, a claimed WebIDs can only be considered verified if the following steps have been accomplished successfully:</li>
+which are considered claimed <tref>WebID</tref>s at this point, since they have not been verified. The <tref>Verification Agent</tref> may verify as many or as few WebIDs it has time for. It may do it in parallel and asynchronously. However that is done, a claimed WebID can only be considered verified if the following steps have been accomplished successfully:</li>
<ol>
-<li>If the <tref>WebID Verifier</tref> does not have an up to date version of the WebID profile in the cache, then it MUST dereference the WebID using the canonical method for dereferencing a URL of that scheme. For an https://... WebID this would be done using the [[!HTTP-TLS]] protocol. </li>
+<li>If the <tref>WebID Verifier</tref> does not have an up to date version of the WebID profile in the cache, then it MUST dereference the WebID using the canonical method for dereferencing a URL of that scheme. For an <code>https://...</code> WebID this would be done using the [[!HTTP-TLS]] protocol. </li>
<li>The returned representation is then transformed into an RDF graph as specified in <a href="#processing-the-webid-profile">Processing the WebID Profile</a> </li>
<li>That graph is then queried as explained in <a href="#querying-the-graph">Querying the Graph</a>. If the query succeeds, then that WebID is verified.
</li>
@@ -813,13 +813,15 @@
<p>Standard SSLv3 and TLSv1 and upwards can be used to establish the connection between
the Client and the <tref>TLS Agent</tref> 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.
+<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 require the agent to be authenticated in WANT or NEED mode before any further interaction can take place.
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.
-People don't usually feel comfortable authenticating to a web site on the basis of a certificate alone.
-They prefer human readable text, and detailed error messages which the HTTP layer deliver.
+Furthermore very few people will feel comfortable authenticating to a web site on the basis of reading the server certificate alone.
+Most people would like to know more about what the web site claims to be about, before divulging their identity.
+This is usually done by reading a few web pages without having authenticated.
+Hence it is important for human users that authentication be only requested on user demand.
-It is better to move the authentication to the application layer <tref>Guard</tref> as it has a lot more information about the application state.
+This can be done by using TLS renegotiation and moving the authentication to the application layer <tref>Guard</tref> which can make more fine grained decisions on when authentication is required.
Please see the <a href="http://www.w3.org/2005/Incubator/webid/wiki/">WebID Wiki</a> for implementation pointers in different programming languages and platforms to learn about how this can be done and to share your experience.</p>
</section>