--- a/spec/index-respec.html	Wed Nov 30 14:53:37 2011 +0100
+++ b/spec/index-respec.html	Thu Dec 01 17:13:43 2011 +0100
@@ -419,9 +419,12 @@
 The Subject is distinct from the <tref>Client</tref> which is used to connect to the <tref>Server</tref>.
 </dd>
 <dt><tdef>Client</tdef></dt>
-<dd>The Client initiates a request to a Service listening on a specific port using a given protocol on a given Server.
+<dd>The Client initiates a request to a Service listening on a specific port using a given protocol on a given Server. It can request authentication credentials from a <tref>Key Chain</tref> to send to a server
 </dd>
 
+<dt><tdef>Key Chain</tdef> agent</dt>
+<dd>A Key Chain agent can return certificates to authorized <tref>Clients</tref> and can sign cryptographic tokens with the corresponding key.</dd> 
+
 <dt><tdef>Server</tdef></dt>
 <dd>A Server is a machine contactable at a domain name or ip address that hosts a number of globally accessible Services.</dd>
 
@@ -537,19 +540,18 @@
 
 
 <section class='normative'>
-<h1>Creating the certificate</h1>
+<h1>The certificate</h1>
 
-<p>The user agent will create a <tref>Identification Certificate</tref> with a
-<code>Subject Alternative Name</code> URI entry. 
+<p>The <tref>Key Chain</tref> must have a <tref>Certificate</tref> with a <code>Subject Alternative Name</code> URI entry. 
 This URI must be one that dereferences to a document the user controls so that he can publish the
-public key of the <tref>Identification Certificate</tref> at this URI.</p>
+public key for that <tref>Certificate</tref> at this URI.</p>
 <p>For example, if a user Bob controls <code>https://bob.example/profile</code>,
 then his WebID can be <code>https://bob.example/profile#me</code></p>
-<p>When creating a certificate it is very important to put an nice Common Name (CN) for the user, that will allow
-him to distinguish between different certificates he may have, such as a personal or a business certificate. 
+<p>When creating a certificate it is very important to choose a user friendly Common Name (CN) for the user, that will allow him to distinguish between different certificates he may have, such as a personal or a business certificate, when selecting one from his browser. 
 In the example below the CN is <code>Bob (personal)</code>. 
-This name can then also be used by any server authenticating the user to immediately find a way to address the user. 
-The WebID should not usually be used as a visible identifier for human users, rather it should be thought of as a hyperlink in an <code>&lta href="https://..."&gt;</code> code, especially if the resulting resource has an html representation. </p> 
+This name can then also be displayed by any server authenticating the user as a human friendly label. 
+The <tref>WebID</tref> URL itself should not usually be used as a visible identifier for human users, rather it should be thought of as a hyperlink in an <code>&lt;a href="https://..."&gt;</code> anchor. 
+That is the CN should be a label and the <tref>WebID</tref> a pointer. </p> 
 
 <p>As an example to use throughout this specification here is the
 following certificate as an output of the openssl program.</p>
@@ -617,14 +619,21 @@
 <p class="issue">The above certificate is no longer valid, as I took an valid
 certificate and change the time and WebID. As a result the Signatiure is now
 false. A completely valid certificate should be generated to avoid nit-pickers
-picking nits</p>
+picking nits.</p>
+<section class='normative'>
+<h1>Creating a Certificate</h1>
+<p>Many tools exist to create a Certificate. 
+Some keychains allow a user to create the Certificate directly with a friendly User Interface. 
+But using a keychain on the client still requires the public key to be published on the server as detailed in the next section.
+It is possible to combine the creation of the key with its publication in one step in such a way as to allow the server to make the decision of what the WebID should be, by using the <a href="http://www.w3.org/TR/html5/the-button-element.html#the-keygen-element">HTML 5 keygen</a> element. 
+This element can be placed in an html5 form, where on submitting the form, the browser asks the <tref>Key Chain</tref> to create a public and private key pair, and on receiving the public part of that keypair  the Client can sends a keyrequest as part of the form to the <tref>Service</tref>. The <tref>Service</tref> can then create a <tref>WebID Certificate</tref> and return it to the <tref>Client</tref> to pass onto the <tref>KeyChain</tref>. In that way the Server is in the position to best make the decisions of what the <tref>Certificate</tref> should say and what the WebID should be without the private key ever leaving the secure <tref>Key Chain</tref>. The user experience for this Certificate creation is a one click operation.
 </section>
-
+</section>
 
 <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> ontology 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. 
@@ -765,6 +774,7 @@
 &lt;/rdf:RDF&gt;
 </pre>
 <p class="issue">TODO: the dsa ontology</p>
+<p class="todo">What should the time to live be on a WebID document?</p>
 </section>
 <section>
 <h1>In Portable Contacts format using GRDDL</h1>
@@ -772,6 +782,18 @@
 <p class="issue">summarize and point to content negotiation documents</p>
 </section>
 </section>
+<section class='normative'>
+<h1>Disabling a WebID Certificate</h1>
+<p>A <tref>WebID Certificate</tref> is only functional if the <tref>Client</tref> can call on 
+
+ to the public key published in the <tref>  is associated with a private key which the <tref>Subject</tref> needs to take care of keeping secure.
+This can be done by keeping it in the keychain of a personal machine in an account that is password protected and free of viruses, or best of all on some physical device where the private key is inacessible to be read by any software. 
+In the second case having the device implies that the <tref>private key</tref> has not been lost or copied. 
+In the first case the user has to be more careful for signals of misuse.<p>
+<p>In either situation if the <tref>Subject</tref> is suspicious that his private key has been taken, then he can disable future authentications for that certificate by removing the corresponding <tref>public key</tref> from his <tref>WebID Profile</tref>.
+ If the profile contains more than one public key for the <tref>Subject</tref> then it is suggested that each public key contain a label to help the user locate the key. In the examples above an <code>rdfs:label</code> with a creation date was used for this purpose. 
+</p>
+</section>
 </section>
 
 <section class='normative'>
@@ -883,10 +905,11 @@
 <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>The Verification Agent needs to fetch the document, if it does not have a valid one in cache.  The <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 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>
+<p>If the <tref>Guard</tref> wishes to have the most up-to-date Profile document for an https URL, it can use the HTTP cache control headers to get the latest versions.</p>
 </section>
 
 <section class='normative'>