--- a/spec/identity-respec.html Fri Apr 05 13:29:45 2013 -0400
+++ b/spec/identity-respec.html Fri Apr 19 14:39:38 2013 +0200
@@ -62,6 +62,7 @@
berjon.biblio["SWBP-VOCAB-PU"] = "Diego Berrueta, Jon Phipps <a href='http://www.w3.org/TR/swbp-vocab-pub/'><cite>Best Practice Recipes for Publishing RDF Vocabularies</cite></a> W3C Working Group Note 28 August 2008";
berjon.biblio["TURTLE-TR"] = "David Beckett, Tim Berners-Lee. <a href='http://www.w3.org/TR/turtle/'><cite>Turtle: Terse RDF Triple Language.</cite></a> W3C Working Draft 09 August 2011 URL: <a href='http://www.w3.org/TR/turtle/'>http://www.w3.org/TR/turtle/</a> ";
berjon.biblio["FOAF"] = "Dan Brickley, Libby Miller. <a href='http://xmlns.com/foaf/0.1/'><cite>FOAF: Vocabulary Specification 0.98.</cite></a>";
+ berjon.biblio["RDF-XML"] = "Beckett D. (Editor), W3C Recommendation, 10 February 2004. <a href='http://www.w3.org/TR/rdf-syntax-grammar/'><cite>RDF/XML Syntax Specification (Revised)</cite></a>";
// process the document before anything else is done
var refs = document.querySelectorAll('adef') ;
for (var i = 0; i < refs.length; i++) {
@@ -295,17 +296,17 @@
<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
+ <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.
</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
+ <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
+ It does this by applying the best practices of Web Architecture whilst
+ building on well established widely deployed protocols and standards
including HTML, URIs, HTTP, and RDF Semantics.
</p>
@@ -313,9 +314,9 @@
<h2>How to Read this Document</h2>
<p>There are a number of concepts that are covered in this document that the
- reader may want to be aware of before continuing. General knowledge of RDF
- [[!RDF-PRIMER]] is necessary to understand how to implement this specification.
- WebID uses a number of specific technologies like Turtle [[!TURTLE-TR]] and RDFa
+ reader may want to be aware of before continuing. General knowledge of RDF
+ [[!RDF-PRIMER]] is necessary to understand how to implement this specification.
+ WebID uses a number of specific technologies like Turtle [[!TURTLE-TR]] and RDFa
[[!RDFA-CORE]].</p>
<p>A general <a href="#introduction">Introduction</a> is provided for all that
@@ -353,10 +354,10 @@
<p>
A WebID is an HTTP URI which refers to an Agent (Person, Organization, Group, Device, etc.). A description of the WebID can be found in the <tref>Profile Document</tref>, a type of web page that any Social Network user is familiar with.</p>
<p>
-A WebID <tref>Profile Document</tref> is a Web resource that MUST be available as Turtle [[!TURTLE-TR]], but MAY be available in other RDF serialization formats (e.g. [[!RDFA-CORE]]) if requested through content negotiation.
+A WebID <tref>Profile Document</tref> is a Web resource that MUST be available as Turtle [[!TURTLE-TR]], but MAY be available in other RDF serialization formats (e.g. [[!RDFA-CORE]]) if requested through content negotiation.
</p>
<p>
-WebIDs can be used to build a Web of trust using vocabularies such as FOAF [[!FOAF]] by allowing people to link together their profiles in a public or protected manner.
+WebIDs can be used to build a Web of trust using vocabularies such as FOAF [[!FOAF]] 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 he/she is known by some relevant people, works at a given company, is a family member, is part of some group, etc..
</p>
@@ -383,7 +384,7 @@
<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 an agent listening for requests at a given IP address on a given Server.</dd>
+<dd>A Service is an agent listening for requests at a given IP address on a given Server.</dd>
<dt><tdef>WebID</tdef></dt>
<dd>A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, Device, etc.). For WebIDs with fragment identifiers (e.g. #me), the URI without the fragment denotes the Profile Document. For WebIDs without fragment identifiers an HTTP request on the WebID MUST return a 303 with a Location header URI referring to the Profile Document.
@@ -391,7 +392,7 @@
<dt><tdef>WebID Profile</tdef> or <tdef>Profile Document</tdef></dt>
<dd>
-A WebID Profile is an RDF document which MUST uniquely describe the Agent denoted by the WebID in relation to that WebID. This document MUST be available as Turtle [[!TURTLE-TR]]. This document MAY be available in other RDF serialization formats, such as RDFa [[!RDFA-CORE]], RDF/XML [[!RDF-PRIMER]], or N3 [[!N3]] if so requested through content negotiation.
+A WebID Profile is an RDF document which MUST uniquely describe the Agent denoted by the WebID in relation to that WebID. This document MUST be available as Turtle [[!TURTLE-TR]]. This document MAY be available in other RDF serialization formats, such as RDFa [[!RDFA-CORE]], or [[!RDF-XML]] if so requested through content negotiation.
Any other serializations MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]].
</dd>
@@ -448,7 +449,7 @@
<h1>Publishing the WebID Profile Document</h1>
<p>
-WebID requires that servers MUST at least be able to provide Turtle representation of profile documents, but other serialization formats of the graph are allowed, provided that agents are able to parse that serialization and obtain the graph automatically.
+WebID requires that servers MUST at least be able to provide Turtle representation of profile documents, but other serialization formats of the graph are allowed, provided that agents are able to parse that serialization 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.
HTTP Content Negotiation can be employed to aid in publication and discovery of multiple distinct serializations of the same graph at the same URL, as explained by the working group note <a href="http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/">Best Practice Recipes for Publishing RDF Vocabularies</a> [[!SWBP-VOCAB-PUB]]</p>
@@ -460,7 +461,7 @@
<h2>WebID Profile Vocabulary</h2>
<p>WebID RDF graphs are built using vocabularies identified by URIs, that can be placed in subject, predicate or object position of the relations constituting the graph.
- The definition of each URI should be found at the namespace of the URI, by dereferencing it.
+ The definition of each URI should be found at the namespace of the URI, by dereferencing it.
</p>
<section class="informative">
@@ -489,16 +490,20 @@
The syntax is very similar to the <a href="http://www.w3.org/TR/rdf-sparql-query/">SPARQL</a> query language.
Turtle profile documents should be served with the <code>text/turtle</code> content type.
</p>
-<p>
+<p>
Take for example the WebID <em>https://bob.example/profile#me</em>, for which the WebID Profile document contains the following Turtle representation:
</p>
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
- @prefix foaf: <http://xmlns.com/foaf/0.1/> .
+@prefix foaf: <http://xmlns.com/foaf/0.1/> .
- <#me> a foaf:Person;
+<> a foaf:PersonalProfileDocument;
+ foaf:maker <#me>;
+ foaf:primaryTopic <#me>.
+
+<#me> a foaf:Person;
foaf:name "Bob";
foaf:knows <https://example.edu/p/Alice#MSc>;
- foaf:img <http://bob.example/picture.jpg>.
+ foaf:img <https://bob.example/picture.jpg>.
</pre>
</section>
<section class="informative">
@@ -509,7 +514,7 @@
</p>
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
<div vocab="http://xmlns.com/foaf/0.1/" about="#me" typeof="foaf:Person">
- <p>My name is <span property="name">Bob</span> and this is how I look like: <img property="img" src="http://bob.example/picture.jpg" title="Bob" alt="Bob" /></p>
+ <p>My name is <span property="name">Bob</span> and this is how I look like: <img property="img" src="https://bob.example/picture.jpg" title="Bob" alt="Bob" /></p>
<h2>My Good Friends</h2>
<ul>
<li property="knows" href="https://example.edu/p/Alice#MSc">Alice</li>
@@ -540,16 +545,24 @@
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
+<> a foaf:PersonalProfileDocument;
+ foaf:maker <#me>;
+ foaf:primaryTopic <#me>.
+
<#me> a foaf:Person;
foaf:name "Bob";
<strong>rdfs:seeAlso <https://bob.example/friends>;</strong>
- foaf:img <http://bob.example/picture.jpg>.
+ foaf:img <https://bob.example/picture.jpg>.
</pre>
<p>Where https://bob.example/friends is a reference to an ACL protected document containing:</p>
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
+
+<> a foaf:PersonalProfileDocument;
+ foaf:maker <https://bob.example/profile#me>;
+ foaf:primaryTopic <https://bob.example/profile#me>.
<https://bob.example/profile#me> a foaf:Person;
foaf:knows <https://example.edu/p/Alice#MSc>;
@@ -560,7 +573,7 @@
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
-
+
<#FriendsOnly>
<acl:accessTo> <https://bob.example/friends>;
<acl:agent> <http://example.edu/p/Alice#Msc>, <http://example.com/people/Mary/card#me>;
@@ -579,7 +592,7 @@
<section class='normative'>
<h2>Processing the WebID Profile</h2>
-<p>The <tref>Requesting Agent</tref> needs to fetch the document, if it does not have a valid one in cache.
+<p>The <tref>Requesting Agent</tref> needs to fetch the document, if it does not have a valid one in cache.
The Agent requesting the WebID document MUST be able to parse documents in Turtle [[!TURTLE-TR]], but MAY also be able to parse documents in RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and RDFa [[!RDFA-CORE]].
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">
--- a/spec/tls-respec.html Fri Apr 05 13:29:45 2013 -0400
+++ b/spec/tls-respec.html Fri Apr 19 14:39:38 2013 +0200
@@ -51,7 +51,9 @@
berjon.biblio["SWBP-VOCAB-PU"] = "Diego Berrueta, Jon Phipps <a href='http://www.w3.org/TR/swbp-vocab-pub/'><cite>Best Practice Recipes for Publishing RDF Vocabularies</cite></a> W3C Working Group Note 28 August 2008";
berjon.biblio["TURTLE-TR"] = "David Beckett, Tim Berners-Lee. <a href='http://www.w3.org/TR/turtle/'><cite>Turtle: Terse RDF Triple Language.</cite></a> W3C Working Draft 09 August 2011 URL: <a href='http://www.w3.org/TR/turtle/'>http://www.w3.org/TR/turtle/</a>";
berjon.biblio["FOAF"] = "Dan Brickley, Libby Miller. <a href='http://xmlns.com/foaf/0.1/'><cite>FOAF: Vocabulary Specification 0.98.</cite></a>";
+ berjon.biblio["RDF-XML"] = "Beckett D. (Editor), W3C Recommendation, 10 February 2004. <a href='http://www.w3.org/TR/rdf-syntax-grammar/'><cite>RDF/XML Syntax Specification (Revised)</cite></a>";
berjon.biblio["WEBID"] = "Andrei Sambra, Stéphane Corlosquet. <a href='https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html'><cite>WebID 1.0: Web Identity and Discovery.</cite></a>";
+
// process the document before anything else is done
var refs = document.querySelectorAll('adef') ;
for (var i = 0; i < refs.length; i++) {
@@ -347,13 +349,13 @@
<h1>Introduction</h1>
<p>
-The WebID-TLS protocol enables secure, efficient and maximally user friendly authentication on the Web.
-It enables people to authenticate onto any site by simply choosing one of the certificates proposed to them by their browser.
+The WebID-TLS protocol enables secure, efficient and maximally user friendly authentication on the Web.
+It enables people to authenticate onto any site by simply choosing one of the certificates proposed to them by their browser.
These certificates can be created by any Web Site for their users.
-This specification extends the WebID Identity [[!WEBID]] specification which defines a lot of concepts used in WebID-TLS, such as the identifier, known as the <tref>WebID</tref>, as well as the associated <tref>Profile Document</tref>.
+This specification extends the WebID Identity [[!WEBID]] specification which defines many of the core concepts used in WebID-TLS, such as the identifier, known as the <tref>WebID</tref>, as well as the associated <tref>Profile Document</tref>.
</p>
<p>
-WebIDs can be used to build a Web of trust using vocabularies such as [[!FOAF]] by allowing people to link together their profiles in a public or protected manner.
+WebIDs can be used to build a Web of trust using vocabularies such as [[!FOAF]] 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 he/she is known by some relevant people, works at a given company, is a family member, is part of some group, ...</p>
<p>
The WebID-TLS protocol specifies how a <tref>Service</tref> can authenticate a user after requesting his or her <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 private key related to the <tref>Public Key</tref> published in the <tref>Certificate</tref> used to authenticate.
@@ -372,16 +374,16 @@
<dl>
<dt><tdef>WebID</tdef></dt>
-<dd>A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, Device, etc.).
-For WebIDs with fragment identifiers (e.g. #me), the URI without the fragment denotes the Profile Document.
+<dd>A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, Device, etc.).
+For WebIDs with fragment identifiers (e.g. #me), the URI without the fragment denotes the Profile Document.
For WebIDs without fragment identifiers an HTTP request on the WebID MUST return a 303 with a Location header URI referring to the Profile Document. Refer to [[!WEBID]] for the normative definition.
</dd>
<dt><tdef>WebID Profile</tdef> or <tdef>Profile Document</tdef></dt>
<dd>
-A WebID Profile is an RDF document which MUST uniquely describe the Agent denoted by the WebID in relation to that WebID.
-This document MUST be available as Turtle [[!TURTLE-TR]].
-This document MAY be available in other RDF serialization formats, such as RDFa [[!RDFA-CORE]], RDF/XML [[!RDF-PRIMER]], or N3 [[!N3]] if so requested through content negotiation.
+A WebID Profile is an RDF document which MUST uniquely describe the Agent denoted by the WebID in relation to that WebID.
+This document MUST be available as Turtle [[!TURTLE-TR]].
+This document MAY be available in other RDF serialization formats, such as RDFa [[!RDFA-CORE] or RDF/XML [[!RDF-XML]] if so requested through content negotiation.
Any other serializations MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]]. Refer to [[!WEBID]] for the normative definition.
</dd>
@@ -404,9 +406,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.
+<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>
+</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. Refer to [[!WEBID]] for the normative definition.</dd>
@@ -415,10 +417,10 @@
<dd>A Service is an agent listening for requests at a given IP address on a given Server. Refer to [[!WEBID]] for the normative definition.</dd>
<dt><tdef>TLS Service</tdef></dt>
-<dd>A TLS Service is a transport level service listening on the <tref>Service</tref> port.
+<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 X.509 Certificates containing a public key.
+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 X.509 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>
@@ -426,10 +428,10 @@
<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 X.509 [[!X509V3]] Certificates. </dd>
<dt><tdef>Certificate Authority</tdef> (<tdef>CA</tdef>)</dt>
<dd>
-A Certificate Authority is a Subject that signs <tref>Certificates</tref>.
+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.
+<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> or <tdef>TLS Agent</tdef></dt>
<dd>A TLS-Light Service is a standard <tref>TLS Service</tref>, without the CA Based Client Certificate Authentication.
@@ -438,17 +440,17 @@
</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 to be authorized by looking at the access control rules for that resource.
+<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 to be authorized by looking at the access control rules for that resource.
If the request requires authorization, the Guard can first demand authentication of the <tref>Client</tref> and use the <tref>WebID Verifier</tref> to check any claimed identies that would allow it to come to an authorization decision.
-Finally the Guard can grant or deny access according to how the verfied identities satisfy the Access Control Rules.
+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> or <tdef>Claimed WebID</tdef></dt>
-<dd>A <tref>WebID Certificate</tref> can be thought of as 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 <code>Subject Alternative Name</code>s 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 <code>Subject Alternative Name</code> and the public key in the certificate.
-In Turtle this can be written as
+<dd>A <tref>WebID Certificate</tref> can be thought of as 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 <code>Subject Alternative Name</code>s 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 <code>Subject Alternative Name</code> 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 "00cb24ed85d64d794b..."^^xsd:hexBinary;
@@ -457,15 +459,15 @@
</dd>
<dt><tdef>Verification Agent</tdef> or <tdef>WebID Verifier</tdef></dt>
-<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.
+<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-TR]], RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and RDFa [[!RDFA-CORE]].
</dd>
<dt><tdef>WebID Certificate</tdef></dt>
<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 <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>.
+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 <tref>WebID</tref> <code>https://bob.example/profile#me</code> would contain the following:
<pre class="example">
@@ -526,16 +528,16 @@
<section class='normative'>
<h1>The certificate</h1>
-<p>The <tref>Key Store</tref> must have a <tref>Certificate</tref> with a <code>Subject Alternative Name</code> URI entry.
+<p>The <tref>Key Store</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 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 <tref>WebID</tref> can be <code>https://bob.example/profile#me</code></p>
-<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 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>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 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>
@@ -606,10 +608,10 @@
picking nits.</p>
<section class='normative'>
<h1>Creating a Certificate</h1>
-<p>Many tools exist to create Certificates.
-Some <tref>Key Store</tref>s allow a user to create the Certificate directly with a friendly User Interface.
+<p>Many tools exist to create Certificates.
+Some <tref>Key Store</tref>s allow a user to create the Certificate directly with a friendly User Interface.
But using a <tref>Key Store</tref> 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 <tref>WebID</tref> 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.
+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 <tref>WebID</tref> 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 Store</tref> to create a public and private key pair, and on receiving the public part of that key pair, the Client can send a key request 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>Key Store</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 <tref>WebID</tref> should be without the private key ever leaving the secure <tref>Key Store</tref>. The user experience for this Certificate creation is a one click operation.
</section>
</section>
@@ -621,8 +623,8 @@
<p>The <tref>WebID Profile</tref> document MUST expose the relation between the <tref>WebID</tref> URI and the <tref>Subject</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 that are of interest to the WebID-TLS 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 personalize the user experience. He can post links to people he knows, where those have <tref>WebID</tref>s published on other sites, in order to create a distributed Social Web.
+<p>The document can publish many more relations that are of interest to the WebID-TLS 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 personalize the user experience. He can post links to people he knows, where those have <tref>WebID</tref>s 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>
<p>
@@ -632,14 +634,14 @@
<h2>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.
+ 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
+<p>The following properties SHOULD be used when conveying the relation between the
<tref>Subject</tref> and his or her key, within <tref>WebID Profile</tref> documents:</p>
<dl>
<dt><a href="http://www.w3.org/ns/auth/cert#RSAPublicKey">cert:RSAPublicKey</a></dt>
@@ -692,13 +694,13 @@
</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 that <tref>Subject</tref> is the only one to control the corresponding private key.
+<p>A <tref>WebID Certificate</tref> identifies the <tref>Subject</tref> alone and no one else, if and only if that <tref>Subject</tref> 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 Store</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.
+This can be done by keeping it in the <tref>Key Store</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, future authentications for that certificate can be disabled by removing the corresponding <tref>public key</tref> from the <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.
+ 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>
@@ -714,7 +716,7 @@
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 <tref>WebID</tref>s 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.
+ 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">
@@ -792,9 +794,9 @@
the Client and the <tref>TLS Agent</tref> listening on the Service's port. </p>
<p class="note">Many servers allow a simple form of TLS client side authentication to be setup when configuring a <tref>TLS Agent</tref>: they require the agent to be authenticated in WANT or NEED mode before any further interaction can take place.
If the client sends a certificate, then neither of these have an impact on the <tref>WebID Verification</tref> steps (4) and (5).
-Nevertheless, from a user interaction perspective both of these are problematic as they either force (NEED) or ask the user to authenticate himself even if the resource he wishes to interact with is public and requires no authentication.
+Nevertheless, from a user interaction perspective both of these are problematic as they either force (NEED) or ask the user to authenticate himself even if the resource he wishes to interact with is public and requires no authentication.
Furthermore very few people will feel comfortable authenticating to a web site on the basis of reading the server certificate alone.
-Most people would like to know more about what the web site claims to be about before divulging their identity.
+Most people would like to know more about what the web site claims to be about before divulging their identity.
This is usually done by reading a few web pages without being authenticated.
Hence it is important for human users that authentication be only requested on user demand.
@@ -820,9 +822,9 @@
<p class="note">From our experience leaving the certificate_authorities field empty leads to the correct behavior on all browsers and all TLS versions.</p>
<p class="note">A security issue with TLS renegotiation was discovered in 2009, and an IETF fix was proposed in [[!RFC5746]] which is widely implemented.</p>
<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 much 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 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>As much 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 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>
@@ -832,23 +834,23 @@
<p>The <tref>Verification Agent</tref> is given a list of <tref>WebID</tref>s associated with a public key. It needs to verify that the agent identified by that <tref>WebID</tref> is indeed the agent that controls the private key of the given public key. It does this by looking up the definition of the <tref>WebID</tref>. A <tref>WebID</tref> is a URI, and its meaning can be obtained by dereferencing it using the protocol indicated in its scheme. </p>
<p>If we first consider <tref>WebID</tref>s 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 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 a <tref>WebID</tref> containing a fragment identifier, one needs to dereference the resource referred to without the fragment identifier.
-This resource will describe the referent of the <tref>WebID</tref> using a syntax convertible to RDF triples.
+<p>In order therefore to know the meaning of a <tref>WebID</tref> containing a fragment identifier, one needs to dereference the resource referred to without the fragment identifier.
+This resource will describe the referent of the <tref>WebID</tref> using a syntax convertible to RDF triples.
If the document returned states that the referent of the <tref>WebID</tref> 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 <tref>WebID</tref>: 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 <tref>WebID</tref>.
+<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 <tref>WebID</tref>.
An HTTPS <tref>WebID</tref> will therefore be a lot more trustworthy than an HTTP <tref>WebID</tref> 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 <tref>WebID</tref> 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>The Verification Agent needs to fetch the document, if it does not have a valid one in cache.
+<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-TR]], and MAY be able to also parse them in RDFa [[!RDFA-CORE]] and RDF/XML [[!RDF-SYNTAX-GRAMMAR]].
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">
@@ -910,7 +912,7 @@
</section>
<section class="normative">
<h2>Verifying the WebID claim without SPARQL</h2>
-<p>If the RDF library does datatype normalization 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>If the RDF library does datatype normalization 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 normalize 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 normalized 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>
@@ -919,9 +921,9 @@
<h2>Authorization</h2>
<p>The Authorization step may be as simple as just allowing everybody read access. The authentication phase may then just have been useful in order to gain some extra information from the <tref>WebID Profile</tref> in order to personalize a site -- e.g. displaying a user's picture.</p>
-<p>Once the <tref>Guard</tref> has a <tref>WebID</tref> he can do a lookup in a database to see if the agent is allowed the required access to the given resource.
+<p>Once the <tref>Guard</tref> has a <tref>WebID</tref> 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 personalize the site for the requestor.
-But the interesting thing about such a <tref>WebID</tref> 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.
+But the interesting thing about such a <tref>WebID</tref> 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 therefore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friends and those friends' friends (FOAF), stated by them at their domains.
It is even 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.