--- a/index-respec.html	Tue Aug 10 17:28:38 2010 -0400
+++ b/index-respec.html	Tue Aug 10 17:31:38 2010 -0400
@@ -14,7 +14,7 @@
 
 span.hilite { color: red; /* font-weight: bold */ }
 
-li p           { margin-top: 0.3em;
+li p           { margin-top: 0.3em; li
                  margin-bottom: 0.3em; }
 
 div.explanation { background-color: #ADD8E6;
@@ -379,7 +379,7 @@
 Agent to a URI by proving that one has write access to the URI.
 WebID is an authentication protocol which uses X.509 
 certificates to associate a User Agent (Browser) to a Person identified via a URI.
-WebID is compatible with OpenID and provides a few additional features such as
+A WebID profile can also be used for OpenID, WebId provides a few additional features such as
 trust management via digital signatures, and free-form 
 extensibility via RDF. By using the existing SSL certificate exchange
 mechanism, WebID integrates smoothly with existing Web browsers, including
@@ -392,6 +392,7 @@
 </section>
 
 </section>
+
 <section>
 <h1>Preconditions</h1>
 
@@ -411,7 +412,7 @@
 <tref>Identification Agent</tref> is typically also a User Agent.</dd>
 
 <dt><tdef>Identification Certificate</tdef></dt>
-<dd>An X.509 [[!X509V3]] Certificate that MUST contain a 
+<dd>An X.509 [[!X509V3]] Certificate that MUST contain exactly one 
 <code>Subject Alternative Name</code> extension with a URI entry. The URI
 identifies the <tref>Identification Agent</tref>. The URI SHOULD be
 dereference-able and result in a document containing RDF data. For example, 
@@ -628,7 +629,7 @@
 &lt;/html&gt;
 </pre>
 </p>
-<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 should publish the link from the HTML to the machine readable format as follows:</p>
+<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) as follows:</p>
  <p class="example">
 <pre>
 &lt;html&gt; 
@@ -657,7 +658,6 @@
 <h1>The WebID Protocol</h1>
 
 <section class='normative'>
-<section class='normative'>
 <h1>Authentication Sequence</h1>
 
 <p>The following steps are executed by <tref>Verification Agent</tref>s and
@@ -676,8 +676,24 @@
 
 <li>The <tref>Verification Agent</tref> MUST extract the <tref>public key</tref> and the
 <tref>WebID URI</tref> contained in the <code>Subject Alternative Name</code>
-extension of the <tref>Identification Certificate</tref>.
-<p class="issue">There may be more than one URI in the SAN</p></li>
+extension of the <tref>Identification Certificate</tref>.</li>
+
+<li>The <tref>public key</tref> information associated with the 
+<tref>WebID URI</tref> MUST be checked by the <tref>Verification Agent</tref>.
+This process SHOULD occur either by dereferencing the <tref>WebID URI</tref> and
+extracting RDF data from the resulting document, or by utilizing a cached 
+version of the RDF data contained in the document or other data source that is 
+up-to-date and trusted by the <tref>Verification Agent</tref>. The processing
+and extraction mechanism is further detailed in the sections titled 
+<a href="#processing-the-webid-profile">Processing the WebID Profile</a> and
+<a href="#extracting-webid-URI-details">Extracting WebID URI Details</a>.
+</li>
+
+<li>If the <tref>public key</tref> in the 
+<tref>Identification Certificate</tref> is found in the list of 
+<tref>public key</tref>s associated with the <tref>WebID URI</tref>, the
+<tref>Verification Agent</tref> MUST assume that the client intends to use
+this <tref>public key</tref> to verify their ownership of the <tref>WebID URI</tref>.</li>
 
 <li>
 The <tref>Verification Agent</tref> verifies that the 
@@ -686,23 +702,10 @@
 between the <tref>Verification Agent</tref> and the 
 <tref>Identification Agent</tref>. 
 If the <tref>Verification Agent</tref> does not have access to the TLS layer, 
-a digital signature challenge MAY be provided by the 
-<tref>Verification Agent</tref>. These processes are detailed in the section
-on  
-<a href="#secure-communication">Secure Communication</a>.
-<p class="issue">We don't have any implementations for this second way of doing 
-things, so this is still hypothetical. Implementations using TLS mutual-authentication are many</p>
-</li>
-
-<li>The meaning of the 
-<tref>WebID URI</tref> is a graph of relations that is fetched by the <tref>Verification Agent</tref> 
-either by dereferencing the <tref>WebID URI</tref> and 
-extracting RDF data from the resulting document, or by utilizing a cached 
-version of the RDF data contained in the document or other data source that is 
-up-to-date and trusted by the <tref>Verification Agent</tref>. The processing
- mechanism is further detailed in the sections titled 
-<a href="#processing-the-webid-profile">Processing the WebID Profile</a>
-</li>
+a digital signature challenge MUST be provided by the 
+<tref>Verification Agent</tref>. These processes are detailed in the sections 
+titled <a href="#authorization">Authorization</a> and 
+<a href="#secure-communication">Secure Communication</a>.</li>
 
 <li>If the <tref>public key</tref> in the 
 <tref>Identification Certificate</tref> matches one in the set given by the
@@ -765,10 +768,13 @@
 <h2>Verifying the WebID is identified by that public key</h2>
 
 <p>
-The <tref>Verification Agent</tref> must check that the <tref>WebID Profile</tref> associates the WebID with the public key given in the X.509 Certificate. There are number of ways of doing this, each of which essentially consists in checking that the graph of relations in the Profile contain a pattern of relations.
+There are number of different ways to check that the public key given in the X.509 
+certificate against the one provided by the <tref>WebID Profile</tref> or another 
+trusted source, the essence is checking that the graph of relations in the 
+Profile contains a pattern of relations.
 </p>
 <p>Assuming the public key is an RSA key, and that its modulus is
- "9D79BFE2498..." and exponent "65537" then the query to ask the graph is
+ "9D79BFE2498..." and exponent "65537" then the following SPARQL query could be used:
 </p>
 <pre class='example'>
 PREFIX cert: &lt;http://www.w3.org/ns/auth/cert#&gt;
@@ -779,16 +785,24 @@
       rsa:public_exponent "65537"^^cert:int .
 }
 </pre>
-<p>If the query returns true, then the graph has validated the associated public key with the WebID.</p>
-<p>The above requires the graph to be able to do inferencing on dataytypes. This is because people may publish their modulus string in a number of syntactical ways. The modulus can be colon seperated, spread over a number of lines, or contain arbitrary non hex characters such as "9D ☮ 79 ☮ BF ☮ E2 ☮ F4 ☮ 98 ☮..." .  The datatype itself need not necessarily be expressed in cert:hex, but could use a number of xsd integer datatype notations, cert:int or future base64 notations. 
+<p>If the query returns true, then the graph has validated the associated 
+public key with the WebID.</p>
+<p>The above requires the sparql endpoint (or the underlying triple store 
+to be able to do inferencing on dataytypes. This is because the numerical 
+values may be expressed with different xsd and cert datatypes which must all
+be supported by <tref>VerificationAgent</tref>s. The cert datatypes allow
+the numerical expression to be spread over a number of lines, or contain 
+arbitrary characters such as "9D ☮ 79 ☮ BF ☮ E2 ☮ F4 ☮ 98 ☮..." .  The datatype
+itself need not necessarily be expressed in cert:hex, but could use a number of
+xsd integer datatype notations, cert:int or future base64 notations. 
 </p>
 <p class="issue">Should we define the base64 notation?</p>
-<p>If a <tref>Verifying Agent</tref> does not have access to a literal inferencing engine, then the modulus should be extracted from the graph, normalised into a big integer (integers without an upper bound), and compared with the values given in the public key certificate. After replacing the <code>?webid</code> variable in the following query with the required value the <tref>Verifying Agent</tref> can query the Profile Graph with</p>
+<p>If the SPARQL endpoint doesn't provide a literal inferencing engine, then the modulus should be extracted from the graph, normalised into a big integer (integers without an upper bound), and compared with the values given in the public key certificate. After replacing the <code>?webid</code> variable in the following query with the required value the <tref>Verifying Agent</tref> can query the Profile Graph with</p>
 <pre class='example'>
 PREFIX cert: &lt;http://www.w3.org/ns/auth/cert#&gt;
 PREFIX rsa: &lt;http://www.w3.org/ns/auth/rsa#&gt;
 SELECT ?m ?e 
-WHERE { 
+WHERE {
    [] cert:identity ?webid ;
         rsa:modulus ?m ;
         rsa:public_exponent ?e .