--- a/spec/index-respec.html Sun Dec 18 11:35:27 2011 +0100
+++ b/spec/index-respec.html Mon Jan 09 13:45:05 2012 +0100
@@ -291,7 +291,7 @@
<p>A global distributed Social Web requires that each person be able to control their identity, that this identity be linkable across sites - placing each person in a Web of relationships - and that it be possible to authenticate globally with such identities. By making distributed authentication easy one can allow everybody to protect their resources and enable their preferred privacy settings.</p>
<p>This specification outlines a simple universal identification mechanism that is distributed, openly extensible, improves privacy, security and control over how each person can identify themselves in order to allow fine grained access control to their information on the Web.
-It does this by applying the best practices of Web Architecture whilst building on well established widely deployed protocols and standards including HTML, XHTML, URIs, HTTP, TLS, X509 Certificates, and RDF Semantics.
+It does this by applying the best practices of Web Architecture whilst building on well established widely deployed protocols and standards including HTML, XHTML, URIs, HTTP, TLS, X.509 Certificates, and RDF Semantics.
</p>
<section>
@@ -395,12 +395,12 @@
<dd>A TLS Service is a transport level service listening on the <tref>Service</tref> port.
It secures the transport layer before passing messages to the Application layer <tref>Service</tref> itself.
The TLS protocol [[!RFC5246]] is applied to incoming connections: it identifies the server to the client, securing the channel and is able to request authentication credentials from the <tref>Client</tref> if needed.
-Server Credentials and Client credentials traditionally take the form of X509 Certificates containing a public key.
+Server Credentials and Client credentials traditionally take the form of X.509 Certificates containing a public key.
The TLS protocol enables the TLS Service to verify that the <tref>Client</tref> controls the private key of the <tref>Public Key</tref> published in the certificate.
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 X.509 [[!X509V3]] Certificates. </dd>
<dt><tdef>Certificate Authority</tdef> (<tdef>CA</tdef>)</dt>
<dd>
A Certificate Authority is a Subject that signs <tref>Certificates</tref>.
@@ -408,9 +408,9 @@
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>
-<dd>A TLS-Light Service is a standard TLS Service, except that it does not do CA Based Client Certificate Authentication.
-If on requesting a Certificate from a Client it receives one, it simply verifies that the <tref>Client</tref> knows the private key of the public key published in the Certificate it received.
+<dt><tdef>TLS-Light Service</tdef> or <tdef>TLS Agent</tdef></dt>
+<dd>A TLS-Light Service is a standard <tref>TLS Service</tref>, without the CA Based Client Certificate Authentication.
+When receiving a Client Certificate, it simply verifies that the <tref>Client</tref> knows the private key of the public key published in the Certificate.
Verification of attributes in the certificate is left to other services such as the <tref>WebID Verifier</tref>.
</dd>
@@ -434,7 +434,7 @@
This URI SHOULD be one of the URIs with a dereferenceable secure scheme, such as https:// . Dereferencing this URI should return a representation containing RDF data.
For example, a certificate identifying the WebID URI <code>https://bob.example/profile#me</code> would contain the following:
<pre class="example">
-X509v3 extensions:
+X.509v3 extensions:
...
X509v3 Subject Alternative Name:
URI:https://bob.example/profile#me
@@ -597,7 +597,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> ontology 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>Subject</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.
@@ -781,9 +781,9 @@
<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>
-<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 TLS Agent can ask for any Certificate from the Client. More details in <a href="#requesting-the-client-certificate">Requesting the Client Certificate</a></li>
+<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>
<li>The Client asks Bob to choose a certificate if the choice has not been automated. We will assume that Bob does choose a <tref>WebID Certificate</tref> and sends it to the client.</li>
-<li>The <tref>TLS Agent</tref> MUST verify that the client is indeed in possession of the private key. What is important here is that the TLS Agent need not know the Issuer of the Certificate, or need not have any trust relation with the Issuer. Indeed if the TLS Layer could verify the signature of the Issuer and trusted the statements it signed, then step 4 and 5 would not be needed - other than perhaps as a way to verify that the key was still valid.</li>
+<li>The <tref>TLS Agent</tref> MUST verify that the client is indeed in possession of the private key. What is important here is that the <tref>TLS Agent</tref> need not know the Issuer of the Certificate, or need not have any trust relation with the Issuer. Indeed if the TLS Layer could verify the signature of the Issuer and trusted the statements it signed, then step 4 and 5 would not be needed - other than perhaps as a way to verify that the key was still valid.</li>
<li>The <tref>WebID Certificate</tref> is then passed on to the <tref>Guard</tref> with the proviso that the WebIDs still needs to be verified.</li>
</ol>
</li>
@@ -812,7 +812,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 <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.
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.
@@ -953,7 +953,7 @@
<h2>The WebID Profile</h2>
<p>The <tref>WebID Profile</tref> is a structured document that contains
-identification credentials for the <tref>Identification Agent</tref> expressed
+identification credentials for the <tref>Subject</tref> expressed
using the Resource Description Framework [[RDF-CONCEPTS]]. The following
sections describe how to express certain common properties that could be used
by <tref>Verification Agent</tref>s and other entities that consume a
@@ -983,7 +983,7 @@
<h2>Cryptographic Details</h2>
<p>Cryptographic details are important when <tref>Verification Agent</tref>s
-and <tref>Identification Agent</tref>s interact. The following properties
+and <tref>Subject</tref>s interact. The following properties
SHOULD be used when conveying cryptographic information in
<tref>WebID Profile</tref> documents:</p>