some changes I must have made previously
authorHenry J. Story <henry.story@bblfish.net>
Mon, 29 Nov 2010 21:01:38 +0100
changeset 104 c5234ae5aaca
parent 103 b0094b9c560b
child 105 b9c8eba5d659
some changes I must have made previously
index-respec.html
--- a/index-respec.html	Mon Nov 29 21:00:45 2010 +0100
+++ b/index-respec.html	Mon Nov 29 21:01:38 2010 +0100
@@ -179,9 +179,9 @@
 
           // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
           // and its maturity status
-          previousPublishDate:  "2010-07-11",
+          previousPublishDate:  "2010-07-25",
           previousMaturity:  "ED",
-          previousURI:       "http://payswarm.com/webid/drafts/ED-webid-20100711/",
+          previousURI:       "http://payswarm.com/webid/drafts/ED-webid-20100725/",
 
 
           // if there a publicly available Editors Draft, this is the link
@@ -198,7 +198,9 @@
           // only "name" is required
           editors:  [
               { name: "Manu Sporny", mailto:"msporny@digitalbazaar.com",
-                  company: "Digital Bazaar, Inc.", companyURL: "http://blog.digitalbazaar.com/" }
+                  company: "Digital Bazaar, Inc.", companyURL: "http://blog.digitalbazaar.com/" },
+              { name: "Stéphane Corlosquet", mailto:"scorlosquet@gmail.com",
+                  company: "Massachusetts General Hospital", companyURL: "http://massgeneral.org/" }
               ],
 
           // authors, add as many as you like. 
@@ -225,7 +227,7 @@
           
           // alternate formats for this document
           alternateFormats: [
-              { uri: 'diff-20100711.html', 
+              { uri: 'drafts/ED-webid-20100809/diff-20100725.html', 
                   label: "Diff from previous Editors Draft" }],
 
           // URI of the patent status for this WG, for Rec-track documents
@@ -392,6 +394,7 @@
 </section>
 
 </section>
+
 <section>
 <h1>Preconditions</h1>
 
@@ -423,6 +426,7 @@
    X509v3 Subject Alternative Name:
       URI:http://example.org/webid#public
 </pre>
+<p class="issue">TODO: cover the case where there are more than one URI entry</p>
 </dd>
 
 <dt><tdef>WebID URI</tdef></dt>
@@ -445,13 +449,13 @@
 WebID Profile document. Alternate RDF serialization
 formats, such as N3 [[!N3]] or Turtle [[!TURTLE]], MAY be supported by the 
 mechanism providing the WebID Profile document.
+<p class="issue">Whether or not RDF/XML, XHTML+RDFa 1.1, both or neither
+serialization of RDF should be required serialization formats in the 
+specification is currently under heavy debate.</p>
 </dd>
 
 </dl>
 
-<p class="issue">Whether or not RDF/XML, XHTML+RDFa 1.1, both or neither
-serialization of RDF should be required serialization formats in the 
-specification is currently under heavy debate.</p>
 
 </section>
 
@@ -459,12 +463,15 @@
 <section class='normative'>
 <h1>Creating the certificate</h1>
 
-<p>The user agent will create an X.509 Certificate with a Subject Alternative Name URI. The URI must be one that points to a document the user controls, as he will have to add information to that document at that URI. </p>
-<p>Suppose for sake of example that the X.509 Certificate contains the public key
-<p>Example: 
-  User controls http://joe.example/profile then his WebID can be
-  http://joe.example/profile#me
-</p>
+<p>The user agent will create a <tref>Identification 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>
+<p>For example, if a user Joe controls <code>http://joe.example/profile</code>,
+then his WebID can be <code>http://joe.example/profile#me</code></p>
+
+<p class="issue">explain why the WebID URI is different from the URI of the WebID profile document.</p>
+
 <p>As an example to use throughout this specification here is the 
 following certificate as an output of the openssl program.</p>
 <p class="example">
@@ -528,14 +535,19 @@
 <p class="issue">Should we formally require the Issuer to be 
    O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority. This was discussed on the list as allowing servers to distinguish certificates that are foaf+Ssl enabled from others. Will probably need some very deep TLS thinking to get this right.</p>
 <p class="issue">discuss the importance for UIs of the CN</p>
+<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>
 </section>
 
 
 <section class='normative'>
-<h1>Publishing the Profile Document</h1>
+<h1>Publishing the WebID Profile Document</h1>
 
-<p>The profile document must expose the relation between the WebID and the
-<tref>Identification Agent</tref>'s public keys at the location of the <tref>WebID document</tref>. It will do that using the cert, rsa ontologies, and the cert or xsd datatypes.  The set of relations to be published at the <tref>WebID document</tref> can be presented in a graphical notation as follows.</p>
+<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> and <code>rsa</code> ontologies, as well as the
+<code>cert</code> or <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" 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.</p>
 <p>The encoding of this graph is immaterial to the protocol, so long as a well known mapping to the format of the representation to such a graph can be found. Below we discuss the most well known formats, and a method for dealing with new unknown formats as they come along.</p>
@@ -651,11 +663,11 @@
  <p class="issue">summarize and point to content negotiation documents</p>
 </section>
 </section>
+</section>
 <section class='normative'>
 <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
@@ -899,6 +911,7 @@
 
 <section class='appendix informative' id="history">
 <h1>Change History</h1>
+<p><a href="">2010-08-09</a> Updates from WebID community: moved OpenID/OAuth sections to separate document, switched to the URI terminology instead of URL, added "Creating the certificate" and "Publishing the WebID Profile document" sections with a WebID graph and serializations in Turtle and RDFa, improved SPARQL queries using literal notation with cert datatypes, updated list of contributors, and many other fixes.</p>
 <p><a href="http://github.com/msporny/webid-spec/commit/b19d2812901b4511fdf9876c1be53bb36ee3201e">2010-07-25</a> Added WebID Profile section.</p>
 <p><a href="http://github.com/msporny/webid-spec/commit/211d197510ca119c21ae48f3e5aa3f931ea88672">2010-07-18</a> Updates from WebID community related to RDF/XML support, authentication sequence corrections, abstract and introduction updates.</p>
 <p><a href="http://github.com/msporny/webid-spec/commit/a54dee9c242b08edaac617d678215b389dd3556d">2010-07-11</a> Initial version.</p>