--- a/spec/index-respec.html	Mon Jan 09 13:49:56 2012 +0100
+++ b/spec/index-respec.html	Mon Jan 09 14:06:18 2012 +0100
@@ -379,11 +379,11 @@
 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. It can request authentication credentials from a <tref>Key Chain</tref> to send to a 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 Store</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. This protocol does not specify where that agent is: it could be that the <tref>Client</tref> contains his own Key Chain or it could be that the Key Chain is a separate process on the Operating System.</dd> 
+<dt><tdef>Key Store</tdef></dt>
+<dd>A Key Store can return certificates to authorized <tref>Clients</tref> and can sign cryptographic tokens with the corresponding key. This protocol does not specify where the Key Store is located: it could be that the <tref>Client</tref> contains his own Key Store or it could be that the Key Store is a separate process on the Operating System, or even that it is to be found in an external device controlled by the <tref>Subject</tref>.</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>
@@ -506,7 +506,7 @@
 <section class='normative'>
 <h1>The certificate</h1>
 
-<p>The <tref>Key Chain</tref> must have a <tref>Certificate</tref> with a <code>Subject Alternative Name</code> URI entry. 
+<p>The <tref>Key Store</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 for that <tref>Certificate</tref> at this URI.</p>
 <p>For example, if a user Bob controls <code>https://bob.example/profile</code>,
@@ -587,10 +587,10 @@
 <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.
+Some <tref>Key Store</tref> allow a user to create the Certificate directly with a friendly User Interface. 
+But using a <tref>Key Store</tref> 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.
+This element can be placed in an HTML5 form, where on submitting the form, the browser asks the <tref>Key Store</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>Key Store</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 Store</tref>. The user experience for this Certificate creation is a one click operation.
 </section>
 </section>
 
@@ -751,7 +751,7 @@
 <h1>Disabling a WebID Certificate</h1>
 <p>A <tref>WebID Certificate</tref> identifies the <tref>Subject</tref> alone and no one else, if and only if she is the only one to control the corresponding private key. 
 It is very important therefore that the <tref>Subject</tref> take care of keeping the <tref>private key</tref> secure.
-This can be done by keeping it in the <tref>Key Chain</tref> 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 inaccessible to be read by any software. 
+This can be done by keeping it in the <tref>Key Store</tref> 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 inaccessible 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>.