--- a/spec/index-respec.html Tue Jan 10 13:47:58 2012 +0100
+++ b/spec/index-respec.html Tue Jan 10 15:42:03 2012 +0100
@@ -220,7 +220,7 @@
company: "Digital Bazaar, Inc.", companyURL: "http://blog.digitalbazaar.com/" },
{ name: "Toby Inkster", url: "http://tobyinkster.co.uk/" },
{ name: "Henry Story", url: "http://bblfish.net/" },
- { name: "Bruno Harbulot", url: "http://blog.distributedmatter.net/" },
+ { name: "Bruno Harbulot", url: "http://blog.distributedmatter.net/" }
],
// errata: 'http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata',
@@ -615,7 +615,8 @@
<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.
For example Bob can publish a depiction or logo, so that sites he authenticates to can personalise the user experience. He can post links to people he knows, where those have WebIDs published on other sites, in order to create a distributed Social Web.
-He can also publish relations to protected documents, where he keeps more information for people who authenticate, such as his friend Alois or his friends friends who may not yet know him personally, such as Alice.</p>
+He can also publish relations to protected documents, where he keeps more information for people who authenticate, such as his friend Alois or his friends friends who may not yet know him personally, such as Alice.
+</p>
<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.
@@ -640,6 +641,60 @@
XHTML even if it is not marked up in RDFa as this allows people using a
web browser to understand what the information at that URI represents.</p>
<section class='normative'>
+<h2>WebID Profile Vocabulary</h2>
+
+<p>RDF graphs are built using vocabularies defined by URIs, that can be placed in subject, predicate or object position.
+ The definition of each URI should be found at the namespace of the URI, by dereferencing it.
+ Here we list the core cryptographic terms needed, and detail some of the useful optional relations from the foaf
+ vocabulary that we have used in the diagrams.
+</p>
+<section class='normative'>
+<h2>Cryptographic Vocabulary</h2>
+
+<p>The following properties SHOULD be used when conveying the relation between the
+ <tref>Subject</tref> and his key.
+<tref>WebID Profile</tref> documents:</p>
+<dl>
+ <dt><a href="http://www.w3.org/ns/auth/cert#RSAPublicKey">cert:RSAPublicKey</a></dt>
+ <dd>Refers to the class of RSA public key. The RSAPublicKey MUST specify the
+ cert:modulus and cert:exponent properties.</dd>
+ <dt><a href="http://www.w3.org/ns/auth/cert#key">cert:key</a></dt>
+ <dd>Used to associate a WebID URI with an RSAPublicKey. A WebID Profile
+ MUST contain at least one RSAPublicKey that is associated with the
+ corresponding WebID URI.</dd>
+ <dt><a href="http://www.w3.org/ns/auth/cert#modulus">cert:modulus</a></dt>
+ <dd>Used to relate an RSAPublic key to its modulus expressed as a hexBinary.
+ An RSA Key must have one and only one modulus. The datatype of a modulus is xsd:hexBinary.
+ </dd>
+ <dt><a href="http://www.w3.org/ns/auth/cert#exponent">cert:exponent</a></dt>
+ <dd>Used to relate an RSAPublic key to its exponent expressed as an integer.
+ An RSA Key must have one and only one exponent. The datatype of a modulus is xsd:integer.
+ </dd>
+</dl>
+
+</section>
+
+
+<section class="informative">
+<h2>Personal Information</h2>
+
+<p>Personal details are the most common requirement when registering an
+account with a website. Some of these pieces of information include an e-mail
+address, a name and perhaps an avatar image. This section includes
+properties that SHOULD be used when conveying key pieces of personal information
+but are NOT REQUIRED to be present in a <tref>WebID Profile</tref>:</p>
+<dl>
+ <dt>foaf:mbox</dt>
+ <dd>The e-mail address that is associated with the WebID URI.</dd>
+ <dt>foaf:name</dt>
+ <dd>The name that is most commonly used to refer to the individual
+ or agent.</dd>
+ <dt>foaf:depiction</dt>
+ <dd>An image representation of the individual or agent.</dd>
+</dl>
+</section>
+</section>
+<section class='informative'>
<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 communicating over e-mail and on mailing lists, and can then be transformed into RDF/XML automatically.
@@ -651,7 +706,7 @@
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
- <#me> a foaf:Person;
+ <#me> a foaf:Person;
foaf:name "Bob";
foaf:knows <https://example.edu/p/Alois#MSc>;
foaf:weblog <http://bob.example/blog>;
@@ -728,7 +783,6 @@
<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>
</section>
</section>
<section class='normative'>
@@ -761,42 +815,54 @@
<img width="90%" src="img/WebIDSequence-friendly.jpg">
<p>The steps in detail are as follows:</p>
<ol>
-<li><tref>Bob</tref>'s <tref>Client</tref> MUST open a TLS [[!RFC5246]] connection with the server which authenticates itself using well known TLS mechanisms. This MAY be done as the first part of an HTTPS connection [[!HTTP-TLS]].</li>
-<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 authorization and hence 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 <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 <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>
+ <li><tref>Bob</tref>'s <tref>Client</tref> MUST open a TLS [[!RFC5246]] connection with the server which authenticates itself using well known TLS mechanisms.
+ This MAY be done as the first part of an HTTPS connection [[!HTTP-TLS]].
+ </li>
+ <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 authorization and hence 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 <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 <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>
+ <li>The <tref>Guard</tref> then MUST ask the <tref>Verification Agent</tref> to verify that the WebIDs in the WebID Certificate do identify the agent who knows the given public key.
+ </li>
+ <li>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 <tref>Claimed 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 <tref>Claimed WebID</tref> can only be considered verified if the following steps have been accomplished successfully:
+ </li>
+ <ol>
+ <li>If the <tref>WebID Verifier</tref> does not have an up to date version of the WebID profile in the cache, then it MUST dereference the WebID using the canonical method for dereferencing a URL of that scheme.
+ For an <code>https://...</code> WebID this would be done using the [[!HTTP-TLS]] protocol.
+ </li>
+ <li>The returned representation is then transformed into an RDF graph as specified in <a href="#processing-the-webid-profile">Processing the WebID Profile</a>
+ </li>
+ <li>That graph is then queried as explained in <a href="#querying-the-graph">Querying the Graph</a>.
+ If the query is answered positively, 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>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>
-</li>
-<li>The <tref>Guard</tref> then MUST ask the <tref>Verification Agent</tref> to verify that the WebIDs in the WebID Certificate do identify the agent who knows the given public key.</li>
-<li>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 <tref>Claimed 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 <tref>Claimed WebID</tref> can only be considered verified if the following steps have been accomplished successfully:</li>
-<ol>
-<li>If the <tref>WebID Verifier</tref> does not have an up to date version of the WebID profile in the cache, then it MUST dereference the WebID using the canonical method for dereferencing a URL of that scheme.
-For an <code>https://...</code> WebID this would be done using the [[!HTTP-TLS]] protocol.
-</li>
-<li>The returned representation is then transformed into an RDF graph as specified in <a href="#processing-the-webid-profile">Processing the WebID Profile</a> </li>
-<li>That graph is then queried as explained in <a href="#querying-the-graph">Querying the Graph</a>.
-If the query is answered positively, 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>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>
</section>
<section class='normative'>
@@ -898,7 +964,7 @@
}
</pre>
<p>The variables to be replaced for each WebID claim are:</p>
-<table style="text-align: left; border-color: rgb(0, 0, 0); border-collapse: collapse; word=wrap: break-word; white-psace: pre-wrap" border="1" cellpadding="5">
+<table style="text-align: left; border-color: rgb(0, 0, 0); border-collapse: collapse; wordwrap: break-word; white-psace: pre-wrap" border="1" cellpadding="5">
<thead>
<tr>
<th>Variable</th>
@@ -947,68 +1013,18 @@
There are too many possibilities to list them all here.
</p>
-</section>
-</section>
-
-<section class='normative'>
-<h2>The WebID Profile</h2>
-
-<p>The <tref>WebID Profile</tref> is a structured document that contains
-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
-<tref>WebID Profile</tref>.</p>
-
-<section class='normative'>
-<h2>Personal Information</h2>
-
-<p>Personal details are the most common requirement when registering an
-account with a website. Some of these pieces of information include an e-mail
-address, a name and perhaps an avatar image. This section includes
-properties that SHOULD be used when conveying key pieces of personal information
-but are NOT REQUIRED to be present in a <tref>WebID Profile</tref>:</p>
-
-<dl>
- <dt>foaf:mbox</dt>
- <dd>The e-mail address that is associated with the WebID URI.</dd>
- <dt>foaf:name</dt>
- <dd>The name that is most commonly used to refer to the individual
- or agent.</dd>
- <dt>foaf:depiction</dt>
- <dd>An image representation of the individual or agent.</dd>
-</dl>
-</section>
-
-<section class='normative'>
-<h2>Cryptographic Details</h2>
-
-<p>Cryptographic details are important when <tref>Verification Agent</tref>s
-and <tref>Subject</tref>s interact. The following properties
-SHOULD be used when conveying cryptographic information in
-<tref>WebID Profile</tref> documents:</p>
-
-<dl>
- <dt>cert:RSAPublicKey</dt>
- <dd>Expresses an RSA public key. The RSAPublicKey MUST specify the
- cert:modulus and cert:exponent properties.</dd>
- <dt>cert:key</dt>
- <dd>Used to associate a WebID URI with an RSAPublicKey. A WebID Profile
- MUST contain at least one RSAPublicKey that is associated with the
- corresponding WebID URI.</dd>
-</dl>
-<p class="note">cert:identity was previously used to associate an RSAPublicKey
-with a WebID URI. cert:identity has been deprecated in favor of its inverse
-property cert:key. Implementors are encouraged to publish WebID Profile
-Documents using cert:key. During this transitional period, implementations
-consuming WebID Profile Documents might still support the deprecated
-cert:identity as well as the stable cert:key.</p>
-</section>
</section>
</section>
+</section>
+</section>
+<section class="informative">
+ <h2>Security Model</h2>
+ <p class="issue">this is a section that can look at different security issues such as
+ possible attack scenarios.
+ </p>
</section>
<section class='appendix informative' id="history">