--- a/spec/index-respec.html Sun Dec 11 13:45:21 2011 +0100
+++ b/spec/index-respec.html Mon Dec 12 12:16:45 2011 -0500
@@ -287,9 +287,9 @@
<body>
<section id='abstract'>
-<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 allowing each user to protect resources and enable his preferred privacy settings.
-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 such as RDF and TLS.
+<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.
</p>
<section>
@@ -342,66 +342,24 @@
<h1>Introduction</h1>
<p>
-The WebID specification is designed to help alleviate the difficultly that
-remembering different logins, passwords and settings for websites has created.
-It is also designed to provide a universal and extensible mechanism to express
-public and private information about yourself. This section outlines the
-motivation behind the specification and the relationship to other similar
-specifications that are in active use today.
-</p>
-
-<section class='informative'>
-<h1>Motivation</h1>
-
-<p>
-It is a fundamental to the architecture of the Web that anyone - be they an individual and organisation, be able to participate in publishing resources and enableing services available to all.
- This includes how one expresses their identity, public information and personal details to social networks, Web sites and services.
-</p>
-
-<p>
-Semantic Web vocabularies such as Friend-of-a-Friend (FOAF) permit distributed
-hyperlinked social networks to exist. This vocabulary, along with other
-vocabularies, allow one to add information and services protection to
-distributed social networks.
-</p>
-
+The WebID protocol enables secure, efficient and maximally user friendly authentication on the Web.
+It enables people to authenticate onto any site by simply clicking on one of the certificates proposed to them by their browser.
+These certificates can be created by any Web Site for their users in one click.
+The identifier, known as the <tref>WebID</tref>, is a URI whose sense can be found in the associated <tref>Profile Page</tref>, a type of web page that any Social Network user is familiar with.</p>
<p>
-One major criticism of open networks is that they seem to have no way of
-protecting the personal information distributed on the web or limiting
-access to resources. Few people are willing to make all their personal
-information public, many would like large pieces to be protected, making
-it available only to a selected group of agents. Giving access to
-information is very similar to giving access to services. There are many
-occasions when people would like services to only be accessible to
-members of a group, such as allowing only friends, family members,
-colleagues to post an article, photo or comment on a blog. How does one do
-this in a flexible way, without requiring a central point of
-access control?
-</p>
-
+These WebIDs can be used to build a Web of trust using vocabularies such as <a href="http://xmlns.com/foaf/0.1/">foaf</a> by allowing people to link together their profiles in a public or protected manner.
+Such a web of trust can then be used by a <tref>Service</tref> to make authorization decisions, by allowing access to resource depending on the properties of an agent, such that the he is known by some relevant people, works at a given company, is a family member, is part of some group, ...</p>
<p>
-Using a process made popular by OpenID, we show how one can tie a User
-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.
-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
-browsers on mobile devices. WebID also permits automated session login
-in addition to interactive session login. Additionally, all data is encrypted
-and guaranteed to only be received by the person or organization that was
-intended to receive it.
+The WebID protocol specifies how a <tref>Service</tref> can authenticate a user after requesting his <tref>Certificate</tref> without needing to rely on this being signed by a well known Certificate Authority. This is done by dereferencing the <tref>WebID Profile</tref>, and checking if it describes the user as being in control of the the private key related to the <tref>Public Key</tref> published in the <tref>Certificate</tref> she used to authenticate.
</p>
-
-</section>
-
+<p>WebID authentication can also be used for automatic authentication by robots, such as web crawlers of linked data repositories, which could be agents working on behalf of users to help them in their daily tasks. The WebID protocol is not limited to authentication on the World Wide Web, but can work with any TLS based protocol.</p>
+<section>
+<h1>Outline</h1>
+<p>This specification is divided in the following sections.</p>
+<p><a href="#introduction">This section</a> gives a high level overview of the WebID Protocol, and presents the organisation of the specification and the conventions used throughout the document.</p>
+<p><a href="#preconditions">Section 2</a> lists the preconditions that need to be in place for any authentication sequence to be successful: which include the creation of a <tref>WebID Profile</tref> and the creation of a <tref>WebID Certificate</tref></p>
+<p><a href="#the-webid-protocol">Section 3</a> on the WebID Protocol describes in detail how a server can authenticate a user.</p>
</section>
-
-<section>
-<h1>Preconditions</h1>
-
<section>
<h1>Terminology</h1>
<dl>
@@ -414,19 +372,22 @@
</dd>
<dt><tdef>Subject</tdef></dt>
<dd>The Subject is the Agent that is identified by the <tref>WebID</tref>.
-When used correctly it is the Subject who wishes to authenticate to a <tref>Service</tref>.
-When speaking of a particular agent, and in order to improve lisibility in this spec, we will name him <tref>Bob</tref>.
+When used legally it is the Subject who wishes to authenticate to a <tref>Service</tref>.
+We will name him <tref>Bob</tref> throughout this document to improve readability.
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.
+<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>
+<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>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>
+<dd>A Server is a machine contactable at a domain name or IP address that hosts a number of globally accessible Services.</dd>
<dt><tdef>Service</tdef></dt>
-<dd>A Service is a an agent listening for requests at a given ip address on a given Server</dd>
+<dd>A Service is a an agent listening for requests at a given IP address on a given Server</dd>
<dt><tdef>TLS Service</tdef></dt>
<dd>A TLS Service is a transport level service listening on the <tref>Service</tref> port.
@@ -453,11 +414,11 @@
<dt><tdef>Guard</tdef><dt>
<dd>A guard is an agent, usually on the <tref>Server</tref> that can look at a request from the <tref>Client</tref> and decide if it needs Authentication by looking at the Access control Rules.
-If it needs Authentication it can request it, and it can use the <tref>WebId Verifier</tref> to complete identity checks.
+If it needs Authentication it can request it, and it can use the <tref>WebID Verifier</tref> to complete identity checks.
Finally it can grant or deny access.
</dd>
-<dt><tdef>Verification Agent</tdef> or <tdef>WebId Verifier</tdef></dt>
+<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.
@@ -532,24 +493,27 @@
</tbody>
</table>
-<p>The ex: namespace is a URI that refers to Bob's profile, where Bob is an imaginary charcter well known in security circles.</p>
+<p>The ex: namespace is a URI that refers to Bob's profile, where Bob is an imaginary character well known in security circles.</p>
</section>
+</section>
+
+<section>
+<h1>Preconditions</h1>
<section class='normative'>
-<h1>Creating the certificate</h1>
+<h1>The certificate</h1>
-<p>The user agent will create a <tref>Identification Certificate</tref> with a
-<code>Subject Alternative Name</code> URI entry.
+<p>The <tref>Key Chain</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 of the <tref>Identification Certificate</tref> at this URI.</p>
+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>,
then his WebID can be <code>https://bob.example/profile#me</code></p>
-<p>When creating a certificate it is very important to put an nice Common Name (CN) for the user, that will allow
-him to distinguish between different certificates he may have, such as a personal or a business certificate.
+<p>When creating a certificate it is very important to choose a user friendly Common Name (CN) for the user, that will allow him to distinguish between different certificates he may have, such as a personal or a business certificate, when selecting one from his browser.
In the example below the CN is <code>Bob (personal)</code>.
-This name can then also be used by any server authenticating the user to immediately find a way to address the user.
-The WebID should not usually be used as a visible identifier for human users, rather it should be thought of as a hyperlink in an <code><a href="https://..."></code> code, especially if the resulting resource has an html representation. </p>
+This name can then also be displayed by any server authenticating the user as a human friendly label.
+The <tref>WebID</tref> URL itself should not usually be used as a visible identifier for human users, rather it should be thought of as a hyperlink in an <code><a href="https://..."></code> anchor.
+That is the CN should be a label and the <tref>WebID</tref> a pointer. </p>
<p>As an example to use throughout this specification here is the
following certificate as an output of the openssl program.</p>
@@ -612,19 +576,26 @@
<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
+that are foaf+SSL enabled from others. Will probably need some very deep TLS
thinking to get this right.</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
+certificate and change the time and WebID. As a result the signature is now
false. A completely valid certificate should be generated to avoid nit-pickers
-picking nits</p>
+picking nits.</p>
+<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.
+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.
</section>
-
+</section>
<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> ontologies, 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>Identification Agent</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.
@@ -633,7 +604,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 interoperabity 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 is has been decided that the document MUST be published at least in one of RDFa [XHTML-RDFA] or RDF/XML [RDF-SYNTAX-GRAMMAR].
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 not 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:
@@ -653,7 +624,7 @@
<section class='normative'>
<h1>Turtle</h1>
<p>A widely used format for writing RDF graphs by hand is the Turtle notation.
-It is easy to learn to use, is very handy for commmunicating over e-mail and on mailing lists, and can then be transformed into RDF/XML automatically.
+It is easy to learn to use, is very handy for communicating over e-mail and on mailing lists, and can then be transformed into RDF/XML automatically.
It is also very similar to the SPARQL query language.
</p>
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
@@ -677,7 +648,7 @@
<section>
<h1>RDFa HTML notation</h1>
<p>There are many ways of writing out the above graph using RDFa in
-html. Here is just one example of what a WebID profile could look like.</p>
+HTML. Here is just one example of what a WebID profile could look like.</p>
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
@@ -745,6 +716,7 @@
<?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/">
@@ -753,11 +725,11 @@
<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="xsd:hexBinary">
+ <rdfs:label>made on 23 November 2011 on my laptop</rdfs:label>
+ <cert:modulus rdf:datatype="http://www.w3.org/ns/auth/cert#hexBinary">
cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1
</cert:modulus>
- <cert:exponent rdf:datatype="xsd:integer">65537</cert:exponent>
+ <cert:exponent rdf:datatype="http://www.w3.org/ns/auth/cert#integer">65537</cert:exponent>
</cert:RSAPublicKey>
</cert:key>
</foaf:Person>
@@ -765,6 +737,7 @@
</rdf:RDF>
</pre>
<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>
@@ -772,6 +745,17 @@
<p class="issue">summarize and point to content negotiation documents</p>
</section>
</section>
+<section class='normative'>
+<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.
+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>.
+ If the profile contains more than one public key for the <tref>Subject</tref> then it is suggested that each public key contain a label to help the user locate the key. In the examples above an <code>rdfs:label</code> with a creation date was used for this purpose.
+</p>
+</section>
</section>
<section class='normative'>
@@ -781,10 +765,10 @@
<h1>Authentication Sequence</h1>
<p>In order to give the full context of a <tref>Client</tref> interaction with a <tref>Server</tref> we will illustrate the protocol with the following sequence diagram.
- <tref>Bob</tref> initiates a connection to <tref>Alice</tref>'s server via a TLS enabled protocol such as https in order to access a Protected Resource or a Protected Service.
+ <tref>Bob</tref> initiates a connection to <tref>Alice</tref>'s server via a TLS enabled protocol such as HTTPS in order to access a Protected Resource or a Protected Service.
The Protected Resource MUST be served over a <tref>TLS-Light Service</tref>, that will not do full <tref>CA</tref> authentication of <tref>Client</tref> <tref>Certificate</tref>s it receives.
-The Protected Resource may be a document served over https, but it could also be a SOAP service, or some other resource.
-This resource is protected by a Guard, which uses a <tref>WebID Verifier</tref> to verify the non Certified WebIds found in the certificate.
+The Protected Resource may be a document served over HTTPS, but it could also be a SOAP service, or some other resource.
+This resource is protected by a Guard, which uses a <tref>WebID Verifier</tref> to verify the non Certified WebIDs found in the certificate.
Once the verification succeeds the Guard checks to see if the Agent identified by the <tref>WebID</tref> is allowed access to the resource, by using trusted information from the Web and access control rules.
</p>
@@ -797,11 +781,11 @@
<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 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 posession 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 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>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>
-<li>The <tref>Guard</tref> then MUST ask the <tref>Verfication Agent</tref> to verify that the WebIDs do identify the agent who knows the given public key.</li>
+<li>The <tref>Guard</tref> then MUST ask the <tref>Verification Agent</tref> to verify that the WebIDs do identify the agent who knows the given public key.</li>
<li>The WebID is verified by looking up the definition of the URL at its canonical location. This can be done by dereferencing it. The <tref>Verification Agent</tref> MUST extract the <tref>public key</tref> and all the URI entries contained in the <code>Subject Alternative Name</code> extension of the <tref>WebID Certificate</tref>. A <tref>WebID Certificate</tref> MAY contain multiple URI entries
which are considered claimed <tref>WebID</tref>s at this point, since they have not been verified. The <tref>Verification Agent</tref> may verify as many or as few WebIDs it has time for. It may do it in parallel and asynchronously. However that is done, a claimed WebIDs can only be considered verified if the following steps have been accomplished successfully:</li>
<ol>
@@ -810,7 +794,7 @@
<li>That graph is then queried as explained in <a href="#querying-the-graph">Querying the Graph</a>. If the query succeeds, then that WebID is verified.
</li>
</ol>
-<li>With the set of verified WebIds the Guard can then check its access control rules using information from the web and other information available to it, to verify if the referent of the WebID is indeed allowed access to the protected resource. The exact nature of those Access Control Rules is left for another specification. Suffice it to say that it can be something as simple as a lookup in a table.</li>
+<li>With the set of verified WebIDs the Guard can then check its access control rules using information from the web and other information available to it, to verify if the referent of the WebID is indeed allowed access to the protected resource. The exact nature of those Access Control Rules is left for another specification. Suffice it to say that it can be something as simple as a lookup in a table.</li>
<li>If access is granted, then the guard can pass on the request to the protected resource, which can then interact unimpeded with the client.</li>
</ol>
<ol>
@@ -857,13 +841,13 @@
<p>If the Client does not send a certificate, because either it does not have one or it does not wish to send one, other authentication procedures can be pursued at the application layer with protocols such as OpenID, OAuth, BrowserID, etc... </p>
<p>As far as possible it is important for the server to request the client certificate in <code>WANT</code> mode, not in <code>NEED</code> mode.
If the request is made in <code>NEED</code> mode then connections will be broken off if the client does not send a certificate.
-This will break the connection at the application protocol layer, and so will lead to a very bad user experience. The server should therfore avoid doing this unless it can be confident that the client has a certificate - which it may be because the client advertised that in some other way to the server.
+This will break the connection at the application protocol layer, and so will lead to a very bad user experience. The server should therefore avoid doing this unless it can be confident that the client has a certificate - which it may be because the client advertised that in some other way to the server.
</p>
<p class="issue">Is there some normative spec about what NEED and WANT refer to?</p>
</section>
<section class='normative'>
-<h2>Verifiying the WebIDs</h2>
+<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]]
<blockquote>
@@ -877,16 +861,17 @@
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>
<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 likelyhood of man in the middle attacks.</p>
-<p>Once that is proven then the trust one can have in the agent at the end of the TLS connection being the referent of the WebID is related to the trust one has in the cryptography, and the likelyhood that the private key could have been stolen.</p>
+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>
+<p>Once that is proven then the trust one can have in the agent at the end of the TLS connection being the referent of the WebID is related to the trust one has in the cryptography, and the likelihood that the private key could have been stolen.</p>
<p class="issue">Add explanation for URI with redirect.</p>
<section class='normative'>
<h2>Processing the WebID Profile</h2>
-<p>So the Verification Agent needs to fetch the document, if it does not have a valid one in cache. <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 <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 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.
+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>
+<p>If the <tref>Guard</tref> wishes to have the most up-to-date Profile document for an HTTPS URL, it can use the HTTP cache control headers to get the latest versions.</p>
</section>
<section class='normative'>
@@ -895,7 +880,8 @@
<p>
To check a WebID claim one has to find if the graph returned by the profile relates the <tref>WebID</tref> to the <tref>Certificate</tref> <tref>Public Key</tref> with the <code>cert:key</code> relation. In other words one has to check if those statements are present in the graph.</p>
-
+<section class="normative">
+<h2>Verifying the WebID Claim with SPARQL</h2>
<p>Testing for patterns in graphs is what the SPARQL query language is designed to do [[!RDF-SPARQL-QUERY]]. We will first look at how to use this as it is also the simplest method, and then what some other programmatic options may be.</p>
<p>Below is the SPARQL Query Template which should be used for an RSA public key. It contains three variables <code>?webid</code>, <code>?mod</code> and <code>?exp</code> that need to be replaced by the appropriate values:</p>
<pre style="word-wrap: break-word; white-space: pre-wrap;">
@@ -918,7 +904,7 @@
</thead>
<tbody>
<tr><td><code>?webid</code></td><td>should be replaced by the WebID Resource. In the SPARQL notation that is the URL string would be placed between <code><...></code> in the position of the <code>?webid</code> variable. </td></tr>
-<tr><td><code>?mod</code></td><td>should be replaced by the modulus written as a xsd:hexBinary as specified by the <a href="http://www.w3.org/ns/auth/cert#modulus">cert:modulus</a> relation. All leading double 0 bytes (written "00" in hexadecimal) should be removed. The resulting hexadecmial should then be placed in the space of the XXX in <code>"XXX"^^xsd:hexBinary</code> </td></tr>
+<tr><td><code>?mod</code></td><td>should be replaced by the modulus written as a xsd:hexBinary as specified by the <a href="http://www.w3.org/ns/auth/cert#modulus">cert:modulus</a> relation. All leading double 0 bytes (written "00" in hexadecimal) should be removed. The resulting hexadecimal should then be placed in the space of the XXX in <code>"XXX"^^xsd:hexBinary</code> </td></tr>
<tr><td><code>?exp</code></td><td>should be replaced by the public exponent written as an xsd:integer typed literal. In SPARQL as in Turtle notation this can just be written directly as an integer.</td></tr>
</tbody>
</table>
@@ -935,10 +921,15 @@
] .
}
</pre>
-<p>An ASK query simply returns true or false. If it returns true, then the key was found in the graph with the proper relation and the claim has been verified.</p>
-<p class="issue"> The public key could be a DSA key. We need to add an ontology
-for DSA too.</p>
-
+<p>An ASK query simply returns true or false. If it returns true, then the key was found in the graph with the proper relation and the claim is verified.</p>
+<p>In order to allow the class of queries defined by the template above to return true when asked of graphs where the hexBinary or the exponent contains whitespace characters in initial and final position, the query engine MUST support the D-entailment regime for <code>xsd:hexBinary</code> and <code>xsd:integer</code> as specified in <a href="http://www.w3.org/TR/sparql11-entailment/#DEntRegime">SPARQL 1.1 Entailment Regimes</a>.</p>
+<p>For verifiers that do not have access to a SPARQL query engine but can query the RDF data programmatically, it is relatively easy to emulate the above SPARQL query programmatically. There are a number of ways of doing this, some more efficient than others.<p>
+</section>
+<section class="normative">
+<h2>Verifying the WebID claim without SPARQL</h2>
+<p>If the RDF library does datatype normalisation of all literals before loading them, then the most efficient way to execute this would be to start by searching for all triples whose subjects have relation <code>cert:modulus</code> to the literal which in our example was <code>"cb24ed..."^^xsd:hexBinary</code>. One would then iterate through all the subjects of the relations that satisfied that condition, which would most likely never number more than one, and from there filter out all those that were the object of the <code>cert:modulus</code> relation of the <tref>WebID</tref> - in the example <code>bob:me</code>. Finally one would verify that one of the keys that had satisfied those relations also had the <code>cert:exponent</code> relation to the number which in the example above is <code>"65537"^^xsd:integer</code>.
+</p>
+<p>For triples stores that do not normalise literals on loading a graph, the normalization will need to be done after the query results and before matching those with the values from the <tref>Certificate</tref>. Because one could not rely on the modulus having been normalized, one would have to start with the <tref>WebID</tref> - <code>bob:me</code> and find all it's <code>cert:key</code> relations to objects - which we know to be keys - and then iterate through each of those keys' modulus and exponent, and verify if the normalised version of the value of those relation is equal to the numbers found in the certificate. If one such key is found then the answer is <code>true</code>, otherwise the answer will be <code>false</code>.</p>
</section>
</section>
<section class='normative'>
@@ -948,7 +939,7 @@
<p>Once the <tref>Guard</tref> has a WebID he can do a lookup in a database to see if the agent is allowed the required access to the given resource.
Up to this point we are not much more advanced that with a user name and password, except that the user did not have to create an account on Alice's server to identify himself and that the server has some claimed attributes to personalise the site for the requestor.
But the interesting thing about such a WebID is that because it is a global linkable URI, one can build webs of trust that can be crawled the same way the web can be crawled: by following links from one document to another.
-It is therfore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friend and those friends friends (FOAF), stated by them at their domains.
+It is therefore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friend and those friends friends (FOAF), stated by them at their domains.
It is even be possible to allow remote agents to define their own access control rules for parts of the machine's namespace.
There are too many possibilities to list them all here.
</p>
@@ -1017,6 +1008,9 @@
<section class='appendix informative' id="history">
<h1>Change History</h1>
+<p><a href="http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-2011-11-23/">2011-11-23</a>
+Wide ranging changes: Rewrote the Verification algorithm now enhanced with a detailed sequence diagram. Moved to new ontology using xsd:hexBinary datatypes and removed rsa: ontology. Rewrote vocabulary section using clearer names. All these changes required serious rewriting everywhere.
+</p>
<p><a href="https://dvcs.w3.org/hg/WebID/rev/6b60d7335151">2011-02-10</a>
Move to <a href="http://www.w3.org/2005/Incubator/webid/">W3C WebID XG</a>.
Updates from previous unofficial WebID group include changes on
@@ -1046,15 +1040,19 @@
reviews, criticism and input in the creation of this specification:</p>
<ul>
+<li>Thomas Bergwinkl</li>
<li>Tim Berners-Lee</li>
<li>Sarven Capadisli</li>
<li>Melvin Carvalho</li>
+<li>Martin Gaedke</li>
<li>Michael Hausenblas</li>
<li>Kingsley Idehen</li>
<li>Ian Jacobi</li>
<li>Nathan Rixham</li>
<li>Seth Russell</li>
+<li>Andrei Sambra</li>
<li>Jeff Sayre</li>
+<li>Dominik Tomaszuk</li>
<li>Peter Williams</li>
</ul>