--- a/ontologies/cert.n3 Wed Nov 23 20:47:10 2011 +0100
+++ b/ontologies/cert.n3 Wed Nov 30 14:53:37 2011 +0100
@@ -12,10 +12,11 @@
@prefix : <cert#> .
-<cert> a owl:Ontology ;
+<cert#> a owl:Ontology ;
dc:created "2008-11-13"^^xsd:date;
foaf:maker <http://bblfish.net/people/henry/card#me>;
vs:term_status "unstable";
+ rdfs:label "Ontology for Certificates and crypto stuff.";
rdfs:seeAlso <http://lists.foaf-project.org/mailman/listinfo/foaf-protocols>;
rdfs:seeAlso <X509Uml.svg>;
rdfs:seeAlso <rsa>;
@@ -48,6 +49,7 @@
:Certificate a owl:Class;
vs:term_status "unstable";
+ rdfs:isDefinedBy <cert#>;
rdfs:label "Certificate"@en;
rdfs:subClassOf foaf:Document;
rdfs:comment """A certificate is a Document that is signed.
@@ -62,6 +64,7 @@
:X509Certificate a owl:Class;
vs:term_status "unstable";
+ rdfs:isDefinedBy <cert#>;
rdfs:label "X509Certificate";
rdfs:subClassOf :Certificate;
rdfs:seeAlso <http://en.wikipedia.org/wiki/X509>;
@@ -70,21 +73,25 @@
:PGPCertificate a owl:Class;
rdfs:label "PGPCertificate";
vs:term_status "unstable";
+ rdfs:isDefinedBy <cert#>;
rdfs:subClassOf :Certificate;
owl:equivalentClass wot:PubKey;
rdfs:comment "the class of PGP Certificates"@en .
:Signature a owl:Class;
rdfs:label "Signature";
+ rdfs:isDefinedBy <cert#>;
vs:term_status "unstable";
rdfs:comment "the class of signtatures"@en .
:Key a owl:Class;
vs:term_status "unstable";
+ rdfs:isDefinedBy <cert#>;
rdfs:comment "the class of keys"@en .
:PublicKey a owl:Class;
rdfs:label "PublicKey";
+ rdfs:isDefinedBy <cert#>;
vs:term_status "unstable";
rdfs:comment "Public Key";
rdfs:subClassOf :Key .
@@ -92,6 +99,7 @@
:PrivateKey a owl:Class;
rdfs:label "PrivateKey";
rdfs:comment "Private Key"@en ;
+ rdfs:isDefinedBy <cert#>;
rdfs:subClassOf :Key .
# badly named, removing
@@ -106,6 +114,7 @@
:hex a rdfs:Datatype;
rdfs:label "hexadecimal"@en;
+ rdfs:isDefinedBy <cert#>;
rdfs:seeAlso <http://en.wikipedia.org/wiki/Hexadecimal>;
owl:equivalentClass xsd:nonNegativeInteger;
skos:editorialNote """<span xmlns="http://www.w3.org/1999/xhtml"><p>
@@ -157,6 +166,7 @@
:identity a rdf:Property, owl:ObjectProperty;
vs:term_status "archaic";
rdfs:label "identity"@en;
+ rdfs:isDefinedBy <cert#>;
skos:editorialNote """
It turns out that this relation is unintuitive to write out and to name.
One should instead use cert:key
@@ -172,6 +182,7 @@
:key a rdf:Property, owl:ObjectProperty;
vs:term_status "unstable";
rdfs:label "key"@en;
+ rdfs:isDefinedBy <cert#>;
owl:inverseOf :identity;
rdfs:comment """relates an agent to a key - most often the public key."""@en ;
rdfs:domain foaf:Agent;
@@ -179,6 +190,7 @@
:RSAKey a owl:Class;
rdfs:label "RSA Key"@en;
+ rdfs:isDefinedBy <cert#>;
rdfs:subClassOf :Key;
vs:term_status "unstable";
rdfs:comment """
@@ -188,6 +200,7 @@
:RSAPublicKey a owl:Class;
rdfs:label "RSA Public Key"@en;
+ rdfs:isDefinedBy <cert#>;
rdfs:subClassOf :PublicKey, :RSAKey;
vs:term_status "unstable";
rdfs:seeAlso <http://en.wikipedia.org/wiki/RSA>;
@@ -198,6 +211,7 @@
:modulus a owl:DatatypeProperty;
rdfs:label "modulus"@en;
+ rdfs:isDefinedBy <cert#>;
vs:term_status "unstable";
rdfs:comment """
<p>The modulus of an RSA public and private key.
@@ -216,6 +230,7 @@
:exponent a owl:DatatypeProperty;
rdfs:label "exponent"@en;
+ rdfs:isDefinedBy <cert#>;
vs:term_status "unstable";
rdfs:comment """
The exponent used to encrypt the message. Number chosen between
@@ -226,6 +241,7 @@
:privateExponent a owl:DatatypeProperty ;
rdfs:label "private"@en;
+ rdfs:isDefinedBy <cert#>;
vs:term_status "unstable";
rdfs:comment """
The exponent used to decrypt the message
@@ -236,4 +252,3 @@
rdfs:domain :RSAPrivateKey;
rdfs:range xsd:nonNegativeInteger .
-
Binary file spec/img/WebIDSequence-friendly.graffle has changed
Binary file spec/img/WebIDSequence-friendly.jpg has changed
--- a/spec/img/WebIdGraph.graffle Wed Nov 23 20:47:10 2011 +0100
+++ b/spec/img/WebIdGraph.graffle Wed Nov 30 14:53:37 2011 +0100
@@ -421,11 +421,11 @@
</dict>
<dict>
<key>Bounds</key>
- <string>{{265.03873, 281.08032}, {57, 24}}</string>
+ <string>{{244.42542, 281.08032}, {98.226593, 24}}</string>
<key>Class</key>
<string>ShapedGraphic</string>
<key>FitText</key>
- <string>YES</string>
+ <string>Vertical</string>
<key>Flow</key>
<string>Resize</string>
<key>FontInfo</key>
@@ -474,10 +474,8 @@
{\colortbl;\red255\green255\blue255;\red102\green102\blue102;}
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
-\f0\fs24 \cf2 foaf:blog}</string>
+\f0\fs24 \cf2 foaf:weblog}</string>
</dict>
- <key>Wrap</key>
- <string>NO</string>
</dict>
<dict>
<key>Bounds</key>
@@ -658,7 +656,7 @@
<array>
<dict>
<key>Bounds</key>
- <string>{{135.45203, 682.59119}, {49.999588, 18}}</string>
+ <string>{{140.98376, 682.59119}, {69.755203, 18}}</string>
<key>Class</key>
<string>ShapedGraphic</string>
<key>ID</key>
@@ -684,12 +682,12 @@
{\colortbl;\red255\green255\blue255;}
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
-\f0\fs24 \cf0 xsd:int}</string>
+\f0\fs24 \cf0 xsd:integer}</string>
</dict>
</dict>
<dict>
<key>Bounds</key>
- <string>{{121.45161, 682.59119}, {64, 42}}</string>
+ <string>{{121.4516, 682.59119}, {89.287392, 42}}</string>
<key>Class</key>
<string>ShapedGraphic</string>
<key>ID</key>
@@ -981,7 +979,7 @@
</dict>
<dict>
<key>Bounds</key>
- <string>{{70.959244, 542.05835}, {83, 24}}</string>
+ <string>{{71.976471, 542.71881}, {83, 24}}</string>
<key>Class</key>
<string>ShapedGraphic</string>
<key>FitText</key>
@@ -1053,7 +1051,7 @@
<array>
<string>{138.68835, 465.2164}</string>
<string>{110.80666, 541.16266}</string>
- <string>{153.45161, 682.59119}</string>
+ <string>{165.91322, 682.12549}</string>
</array>
<key>Style</key>
<dict>
@@ -1312,7 +1310,7 @@
{\colortbl;\red255\green255\blue255;\red102\green102\blue102;}
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
-\f0\fs24 \cf2 Joe}</string>
+\f0\fs24 \cf2 Bob}</string>
</dict>
</dict>
<dict>
@@ -2511,7 +2509,7 @@
<key>MasterSheets</key>
<array/>
<key>ModificationDate</key>
- <string>2011-11-23 18:52:31 +0000</string>
+ <string>2011-11-30 09:35:54 +0000</string>
<key>Modifier</key>
<string>Henry Story</string>
<key>NotesVisible</key>
@@ -2604,7 +2602,7 @@
<key>SidebarWidth</key>
<integer>120</integer>
<key>VisibleRegion</key>
- <string>{{43.877556, 1.0204082}, {1035.7142, 838.77551}}</string>
+ <string>{{41.836735, 1.0204082}, {1035.7142, 838.77551}}</string>
<key>Zoom</key>
<real>0.98000001907348633</real>
<key>ZoomValues</key>
Binary file spec/img/WebIdGraph.jpg has changed
--- a/spec/index-respec.html Wed Nov 23 20:47:10 2011 +0100
+++ b/spec/index-respec.html Wed Nov 30 14:53:37 2011 +0100
@@ -182,13 +182,13 @@
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
- previousPublishDate: "2010-08-09",
+ previousPublishDate: "2011-10-17",
previousMaturity: "unofficial",
- previousURI: "http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20100809",
+ previousURI: "http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-2011-10-17",
// if there a publicly available Editors Draft, this is the link
- edDraftURI: "http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20110210",
+ edDraftURI: "http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-2011-11-23",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
@@ -200,14 +200,14 @@
// editors, add as many as you like
// only "name" is required
editors: [
- { name: "Stéphane Corlosquet",
- mailto:"scorlosquet@gmail.com",
- company: "Massachusetts General Hospital",
- companyURL: "http://massgeneral.org/" },
- { name: "Henry Story",
+ { name: "Henry Story",
mailto: "henry.story@bblfish.net",
- url: "http://bblfish.net/" }
- ],
+ url: "http://bblfish.net/" },
+ { name: "Stéphane Corlosquet",
+ mailto:"scorlosquet@gmail.com",
+ company: "Massachusetts General Hospital",
+ companyURL: "http://massgeneral.org/" }
+ ],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
@@ -354,10 +354,8 @@
<h1>Motivation</h1>
<p>
-It is a fundamental design criteria of the Web to enable individuals and
-organizations to control how they interact with the rest of society. This
-includes how one expresses their identity, public information and personal
-details to social networks, Web sites and services.
+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>
@@ -410,15 +408,19 @@
<dt><tdef>Alice</tdef></dt>
<dd>Alice is an agent who owns a Server which runs a Service which Bob wishes to Access</dd>
+<dt><tdef>Bob</tdef></dt>
+<dd>Bob is an agent who uses a <tref>Client</tref> to connect to <tref>Alice</tref>'s Service, and who is responsible for the private key the <tref>Client</tref> uses to authenticate to <tref>Service</tref>s.
+If he notices the private key was compromised he needs to take action to disable the public key.
+</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>. The Subject is distinct from the <tref>Client</tref> which is used to connect to the <tref>Server</tref>.</dd>
-
-<dt><tdef>Bob</tdef></dt>
-<dd>Bob is an agent who uses a <tref>Client</tref> to connect to <tref>Alice</tref>'s Service, and who controls the private key the client uses to access the resource.</dd>
-
+<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>.
+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>
+<dd>The Client initiates a request to a Service listening on a specific port using a given protocol on a given Server.
+</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>
@@ -426,6 +428,29 @@
<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>
+<dt><tdef>TLS Service</tdef></dt>
+<dd>A TLS Service is a transport level service listening on the <tref>Service</tref> port.
+It secures the transport layer before passing messages to the Application layer <tref>Service</tref> itself.
+The TLS protocol [[!RFC5246]] is applied to incoming connections: it identifies the server to the client, securing the channel and is able to request authentication credentials from the <tref>Client</tref> if needed.
+Server Credentials and Client credentials traditionally take the form of X509 Certificates containing a public key.
+The TLS protocol enables the TLS Service to verify that the <tref>Client</tref> controls the private key of the <tref>Public Key</tref> published in the certificate.
+Trust decisions on other attributes of the <tref>Subject</tref> published in the Certificate - such as his name - are traditionally based on the trust in the Agent that signed the Certificate - known as a <tref>Certificate Authority</tref>.
+</dd>
+<dt><tdef>Certificate</tdef><dt>
+<dd>A Certificate is a document that affirms statements about a <tref>Subject</tref> such as its <tref>public key</tref> and its name, and that is signed by a <tref>Certificate Authority</tref> using the private key that corresponds to the public key published in its certificate. The Certificate Authority's own Certificate is self signed. Certificates used by TLS are traditionally X509 [[!X509V3]] Certificates. </dd>
+<dt><tdef>Certificate Authority</tdef> (<tdef>CA</tdef>)</dt>
+<dd>
+A Certificate Authority is a Subject that signs <tref>Certificates</tref>.
+It is an Authority for what is written in the Certificate for any Agent that trusts it to be truthful in what it signs.
+Such agents use the knowledge of the CA's public key to verify the statements made by that CA in any of the Certificates it signed.
+<tref>Service</tref>s usually identify themselves with Certificates signed by well known and widely deployed CAs available in all agents.
+</dd>
+<dt><tdef>TLS-Light Service</tdef></dt>
+<dd>A TLS-Light Service is a standard TLS Service, except that it does not do CA Based Client Certificate Authentication.
+If on requesting a Certificate from a Client it receives one, it simply verifies that the <tref>Client</tref> knows the private key of the public key published in the Certificate it received.
+Verification of attributes in the certificate is left to other services such as the <tref>WebID Verifier</tref>.
+</dd>
+
<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.
@@ -433,10 +458,13 @@
</dd>
<dt><tdef>Verification Agent</tdef> or <tdef>WebId Verifier</tdef></dt>
-<dd>Performs authentication on provided WebID credentials.</dd>
+<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>
<dt><tdef>WebID Certificate</tdef></dt>
-<dd>An X.509 [[!X509V3]] Certificate that will identify an Agent using a WebID.
+<dd>An X.509 [[!X509V3]] <tref>Certificate</tref> that will identify an Agent using a <tref>WebID</tref>.
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.
The Certificate MUST contain a <code>Subject Alternative Name</code> extension with at least one URI entry identifying the <tref>Subject</tref>.
@@ -477,25 +505,28 @@
<h1>Namespaces</h1>
<p>Examples assume the following namespace prefix bindings unless otherwise stated:</p>
<table style="text-align: left; border-color: rgb(0, 0, 0); border-collapse: collapse;" border="1" cellpadding="5">
- <tbody>
+ <thead>
<tr>
<th>Prefix</th>
<th>IRI</th>
</tr>
+ </thead>
+ <tbody>
<tr>
- <td>cert</td>
+ <td><code>cert</code></td>
<td>http://www.w3.org/ns/auth/cert#</td>
</tr>
+
<tr>
- <td>xsd</td>
+ <td><code>xsd</code></td>
<td>http://www.w3.org/2001/XMLSchema#</td>
</tr>
<tr>
- <td>foaf</td>
+ <td><code>foaf</code></td>
<td>http://xmlns.com/foaf/0.1/</td>
</tr>
<tr>
- <td>ex</td>
+ <td><code>ex</code></td>
<td>https://bob.example/profile#</td>
</tr>
</tbody>
@@ -635,6 +666,7 @@
bob:me a foaf:Person;
foaf:name "Bob";
foaf:knows <https://example.edu/p/Alois#MSc>;
+ foaf:weblog <http://bob.example/blog>;
:key [ a :RSAPublicKey;
rdfs:label "made on 23 November 2011 on my laptop";
:modulus "cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1"^^xsd:hexBinary;
@@ -657,7 +689,7 @@
<title>Welcome to Bob's Home Page</title>
</head>
<body>
-<!-- WebID HTML snippet-->
+<!-- WebID HTML snippet. The xmlns declarations above can be moved into the div below if needed-->
<div about="#me" typeof="foaf:Person">
<span property="foaf:name">Bob</span>
<h2>My Good Friends</h2>
@@ -672,9 +704,10 @@
<dl>
<dt>Modulus (hexadecimal)</dt>
- <dd property="cert:modulus" datatype="xsd:hexBinary">cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1</dd>
+ <dd style="word-wrap: break-word; white-space: pre-wrap;"
+ property="cert:modulus" datatype="xsd:hexBinary">cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1</dd>
<dt>Exponent (decimal)</dt>
- <dd property="cert:exponent" datatype="xsd:int">65537</dd>
+ <dd property="cert:exponent" datatype="xsd:integer">65537</dd>
</dl>
</div>
</div>
@@ -684,6 +717,7 @@
</body>
</html>
</pre>
+<p>The <code>style="word-wrap: break-word; white-space: pre-wrap;"</code> attributes allow the number to be displayed on more than one line so that it will wrapped across lines and not just continue off to the right of the screen.</p>
<p class="issue">In order to make the above modulus easy to read for humans who may wish to compare it with the modulus in their browser, one can add some javascript. Add some javascript here that adds a : between every two characters, and that splits the line up in chunks.</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
@@ -716,13 +750,14 @@
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="xsd:hexBinary">
-cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1</dd>
+cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1
</cert:modulus>
- <cert:exponent rdf:datatype="xsd:int">65537</cert:exponent>
+ <cert:exponent rdf:datatype="xsd:integer">65537</cert:exponent>
</cert:RSAPublicKey>
</cert:key>
</foaf:Person>
@@ -745,7 +780,12 @@
<section class='normative'>
<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. 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>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.
+ 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.
+ 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>
<img width="90%" src="img/WebIDSequence-friendly.jpg">
@@ -755,7 +795,7 @@
<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 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 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 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>WebID Certificate</tref> is then passed on to the <tref>Guard</tref> with the proviso that the WebIDs still needs to be verified.</li>
@@ -850,22 +890,52 @@
</section>
<section class='normative'>
-<h2>Verifying the WebID is identified by that public key</h2>
+<h2>Verifying the WebID Claim</h2>
<p>
-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>, but the simplest way to explain it is to say that they all have to be equivalent to the following SPARQL queries.
-</p>
-<p>Assuming the public key is an RSA key, and that its modulus is "9D79BFE2498..." and exponent "65537" then the following query should be used:
+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>
+
+
+<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;">
+PREFIX : <http://www.w3.org/ns/auth/cert#>
+PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
+ASK {
+ ?webid :key [
+ :modulus ?mod;
+ :exponent ?exp;
+ ] .
+}
+</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">
+<thead>
+ <tr>
+ <th>Variable</th>
+ <th>Details on its value.</th>
+ </tr>
+</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>?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>
+
+<p>Assuming that we received Bob's key whose modulus starts with <code>cb24ed85d64d794b6...</code> and whose exponent is <code>65537</code> then the following query should be used:
</p>
<pre class='example' style="word-wrap: break-word; white-space: pre-wrap;">
PREFIX : <http://www.w3.org/ns/auth/cert#>
+PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
ASK {
- <https://bob.example/webid#public> :key [
+ <https://bob.example/profile#me> :key [
:modulus "cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1"^^xsd:hexBinary;
:exponent 65537;
] .
}
</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>
@@ -985,6 +1055,7 @@
<li>Nathan Rixham</li>
<li>Seth Russell</li>
<li>Jeff Sayre</li>
+<li>Peter Williams</li>
</ul>
</section>