--- a/spec/index-respec.html Mon Jan 09 17:36:48 2012 +0100
+++ b/spec/index-respec.html Mon Jan 09 20:41:56 2012 +0100
@@ -303,7 +303,7 @@
and RDF [[!RDF-PRIMER]] is necessary to understand how
to implement this specification. WebID uses a number of specific technologies
like HTTP over TLS [[!HTTP-TLS]], X.509 certificates [[!X509V3]],
-RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and XHTML+RDFa [[!XHTML-RDFA]].</p>
+Turtle [[!TURTLE]] and XHTML+RDFa [[!XHTML-RDFA-PRIMER]].</p>
<p>A general <a href="#introduction">Introduction</a> is provided for all that
would like to understand why this specification is necessary to simplify usage
@@ -383,7 +383,9 @@
</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>
+<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 its 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>
@@ -420,16 +422,28 @@
Finally the Guard can grant or deny access according to how the verfied identities satisfy the Access Control Rules.
</dd>
+<dt><tdef>WebID Claim</tdef></dt>
+<dd>A <tref>WebID Certificate</tref> can be thought of a set of statements made and signed by a <tref>Certificate Authority</tref>.
+If the Certificate Authority is not known to be one whose every statement can be trusted, then the statements in the certificate must be thought of by a suspicious guard, as claimed statements only, that is as statements which have not been verified.
+In particular statements about the Subject Alternative Names of the agent that knows the private key, should not be assumed to be true until verified.
+A WebID Claim then is the statement of Identity between the a Subject Alternative name and the public key in the certificate.
+In Turtle this can be written as
+ <pre class="example">
+ :bob cert:key [ a cert:RSAPublicKey;
+ cert:modulus "00:cb:24:ed:85:d6:4d:79:4b..."^^xsd:hexBinary;
+ cert:exponent 65537 ] .
+ </pre>
+</dd>
+
<dt><tdef>Verification Agent</tdef> or <tdef>WebID Verifier</tdef></dt>
-<dd>A WebID Verifier takes a <tref>WebID Certificate</tref> and verifies that the <tref>Subject</tref> of the Certificate is indeed identified by the <code>Subject Alternative Name</code> <tref>WebID</tref> published there.
-This is usually done, because the <tref>TLS Service Light</tref> did not verify the SAN using a <tref>Certificate Authority</tref> signature.
-But it can also be done to verify that the <tref>Certificate</tref> is still valid.
+<dd>A WebID Verifier takes a <tref>WebID Claim</tref> and checks that it is currently true, as explained in <a href="#verifying-the-webids">Verifying the WebIDs</a> section.
+A WebID Verification Agent MUST be able to parse documents in TURTLE [[!TURTLE]] , RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and RDFa [[!RDFA-SYNTAX]].
</dd>
<dt><tdef>WebID Certificate</tdef></dt>
-<dd>An X.509 [[!X509V3]] <tref>Certificate</tref> that will identify an Agent using a <tref>WebID</tref>.
+<dd>An X.509 [[!X509V3]] <tref>Certificate</tref> that identifes an Agent using one or more <tref>WebID</tref>s.
The Certificate need not be signed by a well known Certificate Authority.
-Indeed it can be signed by the server which hosts the certificate, or it can even be self signed.
+Indeed it can be signed by the server which hosts the <tref>WebID Profile</tref>, or it can even be self signed.
The Certificate MUST contain a <code>Subject Alternative Name</code> extension with at least one URI entry identifying the <tref>Subject</tref>.
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:
@@ -444,7 +458,7 @@
</dd>
<dt><tdef>WebID</tdef></dt>
-<dd>A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions. The WebID should be a URI which when dereferenced returns a representation whose description uniquely identifies the Agent who is the controller of a public key. In our example the WebID refers to <tref>Bob</tref>. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in this document.</dd>
+<dd>A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions. The WebID should be a URI which when dereferenced returns a representation whose description uniquely identifies the Agent who is the controller of a public key. In our example the WebID refers to <tref>Bob</tref>. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in the document refered to by the WebID URL without the #tag .</dd>
</dd>
<dt><tdef>Public Key</tdef></dt>
@@ -454,10 +468,10 @@
<dt><tdef>WebID Profile</tdef> or <tdef>Profile Page</tdef></dt>
<dd>
A structured document asserting the relationship between the Subject (identified by his WebID) and his <tref>Public Key</tref>s using relationships as defined by the Resource Description Framework [[RDF-CONCEPTS]] and published at the URL location of the Subject's WebID.
-Dereferencing the <tref>WebID</tref> should return the Profile Document in one of a number of formats.
-The Server MUST publish the document in at least the XHTML+RDFa 1.1 [[!XHTML-RDFA]] serialization format or in RDF/XML [[!RDF-SYNTAX-GRAMMAR]].
-The document may be published in a number of other RDF serialization formats, such as N3 [[!N3]] or Turtle [[!TURTLE]].
-Any serialisation MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]].
+Dereferencing the <tref>WebID</tref> should return the Profile Page in one of a number of formats.
+The Server MUST publish the document in at least the XHTML+RDFa [[!XHTML-RDFA]] serialization format or in Turtle [[!TURTLE]].
+The document may be published in a number of other RDF serialization formats, such as RDF-XML [[!RDF-PRIMER]], or N3 [[!N3]].
+Any other serialisation MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]].
<p class="issue">Most profiles are currently written out in either of those formats. Whether or not XHTML+RDFa 1.1, both either serialization of RDF should be required serialization formats in the specification is currently under heavy debate and is open to change. </p>
</dd>
@@ -606,7 +620,7 @@
<p>
The protocol does not depend on any particular serialisation of the graph, provided that agents are able to parse that serialisation and obtain the graph automatically.
Technologies such as GRDDL [[!GRDDL-PRIMER]] for example permit any XML format to be transformed automatically to a graph of relations.
-Yet for reasons of interoperability is has been decided that the document MUST be published at least in one of RDFa [XHTML-RDFA] or RDF/XML [[!RDF-SYNTAX-GRAMMAR]].
+Yet for reasons of interoperability the document MUST be published at least one of RDFa [XHTML-RDFA] or TURTLE [[!TURTLE]].
HTTP Content Negotiation [[!SWBP-VOCAB-PUB]] can be employed to aid in publication and discovery of multiple distinct serialisations of the same graph at the same URL. </p>
<p>
Irrespective of whether content negotiation can or cannot be employed, if an HTML representation of the WebID profile is published, it is suggested that the provider uses the HTML <code><link></code> element to allow discovery of the various alternate representations of the graph which may be available:
@@ -709,39 +723,6 @@
</p>
</section>
<section>
-<h1>In RDF/XML</h1>
-<p>RDF/XML is widely supported by RDF tools suites and is usually generated automatically from
-data in object notation or in relational databases.</p>
-
-<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
-<?xml version="1.0"?>
-<rdf:RDF
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
- xmlns:cert="http://www.w3.org/ns/auth/cert#"
- xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
- xmlns:foaf="http://xmlns.com/foaf/0.1/">
- <foaf:Person rdf:about="https://bob.example/profile#me">
- <foaf:name>Bob</foaf:name>
- <foaf:weblog rdf:resource="http://bob.example/blog"/>
- <cert:key>
- <cert:RSAPublicKey>
- <rdfs:label>made on 23 November 2011 on my laptop</rdfs:label>
- <cert:modulus rdf:datatype="http://www.w3.org/2001/XMLSchema#hexBinary">
-cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1
- </cert:modulus>
- <cert:exponent rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">65537</cert:exponent>
- </cert:RSAPublicKey>
- </cert:key>
- </foaf:Person>
-
-</rdf:RDF>
-</pre>
-<p>Notice that the datatype needs to be written out as the full URI in rdf/xml.</p>
-<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>
<p class="issue">TODO: discuss other formats and GRDDL, XSPARQL options for xml formats</p>
<p class="issue">summarize and point to content negotiation documents</p>
@@ -853,16 +834,16 @@
<section class='normative'>
<h2>Verifying the WebIDs</h2>
<p>The <tref>Verification Agent</tref> is given a list of WebIDs associated with a public key. It needs to verify that the agent identified by that WebID is indeed the agent that controls the private key of the given public key. It does this by looking up the definition of the WebID. A WebID is a URI, and it's meaning can be had by dereferencing it using the protocol indicated in its scheme. </p>
-<p>If we first consider WebIDs with fragment identifiers, we can explain the logic of this as follows. As is explained in the RFC defining URIs [[!RFC3986]]
+<p>If we first consider WebIDs with fragment identifiers, we can explain the logic of this as follows. As is explained in the RFC defining URIs [[!RFC3986]]
<blockquote>
The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information.
The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations.
[...]
The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource.
</blockquote>
-<p>In order therefore to know the meaning of WebID containing a fragment identifier, one needs to dereference the resource referred to without the fragment identifier.
-This resource will describe the referent of the WebID in some way.
-If it says that the referent of the WebID is the agent that controls the private key of the given public key, then this is a definite description that can be considered to be a definition of the WebID: it gives its meaning.
+<p>In order therefore to know the meaning of a WebID containing a fragment identifier, one needs to dereference the resource referred to without the fragment identifier.
+This resource will describe the referent of the WebID using a syntax convertible to RDF triples.
+If the document returned states that the referent of the WebID is the agent that controls the private key of the given public key, then this is a definite description that can be considered to be a definition of the WebID: it gives its meaning.
</p>
<p>The trust that can be had in that statement is therefore the trust that one can have in one's having received the correct representation of the document that defined that WebID.
An HTTPS WebID will therefore be a lot more trustworthy than an HTTP WebID by a factor of the likelihood of man in the middle attacks.</p>
@@ -871,7 +852,9 @@
<section class='normative'>
<h2>Processing the WebID Profile</h2>
-<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>The Verification Agent needs to fetch the document, if it does not have a valid one in cache.
+The WebID <tref>Verification Agent</tref> MUST be able to parse documents in TURTLE [[!TURTLE]] , RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and RDFa [[!RDFA-SYNTAX]].
+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>