--- a/spec/index-respec.html Wed Feb 06 16:18:56 2013 +0100
+++ b/spec/index-respec.html Wed Feb 06 16:19:39 2013 +0100
@@ -2,7 +2,7 @@
<!DOCTYPE html>
<html>
<head>
- <title>WebID 1.0</title>
+ <title>WebID-TLS</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<!--
=== NOTA BENE ===
@@ -49,7 +49,8 @@
berjon.biblio["RFC5246"] = "T. Dierks; E. Rescorla. <a href=\"http://tools.ietf.org/html/rfc5246\"><cite>The Transport Layer Security (TLS) Protocol Version 1.2</cite></a> August 2008. Internet RFC 5246. URL: <a href=\"http://tools.ietf.org/html/rfc5246\">http://tools.ietf.org/html/rfc5246</a> ";
berjon.biblio["RFC5746"] = "E. Rescorla, M. Ray, S. Dispensa, N. Oskov, <a href=\"http://tools.ietf.org/html/rfc5746\"><cite>Transport Layer Security (TLS) Renegotiation Indication Extension</cite></a> February 2010. Internet RFC 5246. URL: <a href=\"http://tools.ietf.org/html/rfc5746\">http://tools.ietf.org/html/rfc5746</a> ";
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["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>";
// process the document before anything else is done
var refs = document.querySelectorAll('adef') ;
for (var i = 0; i < refs.length; i++) {
@@ -174,8 +175,8 @@
diffTool: "http://www5.aptest.com/standards/htmldiff/htmldiff.pl",
// the specifications short name, as in http://www.w3.org/TR/short-name/
- shortName: "webid",
- subtitle: "Web Identification and Discovery",
+ shortName: "auth-webid",
+ subtitle: "WebID Authentication over TLS",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
@@ -183,13 +184,13 @@
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
- previousPublishDate: "2011-11-23",
+ previousPublishDate: "2011-12-12",
previousMaturity: "ED",
- previousURI: "http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111123/",
+ previousURI: "http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111212/",
// if there a publicly available Editors Draft, this is the link
- edDraftURI: "http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111212",
+ edDraftURI: "http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20130206",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
@@ -205,9 +206,12 @@
mailto: "henry.story@bblfish.net",
url: "http://bblfish.net/" },
{ name: "Stéphane Corlosquet",
- mailto:"scorlosquet@gmail.com",
- company: "Massachusetts General Hospital",
- companyURL: "http://massgeneral.org/" }
+ mailto:"scorlosquet@gmail.com",
+ company: "Massachusetts General Hospital",
+ companyURL: "http://massgeneral.org/" },
+ { name: "Andrei Sambra",
+ mailto: "andrei@fcns.eu",
+ url: "https://my-profile.eu/people/deiu/card#me" }
],
// authors, add as many as you like.
@@ -225,18 +229,18 @@
// errata: 'http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata',
// name of the WG
- wg: "WebID XG",
+ wg: "WebID CG",
// URI of the public WG page
- wgURI: "http://www.w3.org/2005/Incubator/webid/",
+ wgURI: "http://www.w3.org/community/webid/",
// name (with the @w3c.org) of the public mailing to which comments are due
- wgPublicList: "public-xg-webid",
+ wgPublicList: "public-webid",
// alternate formats for this document
- alternateFormats: [
- { uri: 'http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111212/diff-20111123.html',
- label: "Diff from previous Editors Draft" }],
+ //alternateFormats: [
+ // { uri: 'http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111212/diff-20111123.html',
+ // label: "Diff from previous Editors Draft" }],
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
@@ -299,7 +303,7 @@
reader may want to be aware of before continuing. General knowledge of
<a href="http://en.wikipedia.org/wiki/Public_key_cryptography">public key cryptography</a>
and RDF [[!RDF-PRIMER]] is necessary to understand how
-to implement this specification. WebID uses a number of specific technologies
+to implement this specification. <tref>WebID</tref> uses a number of specific technologies
like HTTP over TLS [[!HTTP-TLS]], X.509 certificates [[!X509V3]],
Turtle [[!TURTLE-TR]] and RDFa [[!RDFA-CORE]].</p>
@@ -328,7 +332,7 @@
enhances the functionality and interoperability of the Web.</p> -->
This document is produced from work by the
-<a href="http://www.w3.org/2005/Incubator/webid/">W3C WebID Incubator Group</a>.
+<a href="http://www.w3.org/community/webid/">W3C WebID Community Group</a>.
This is an internal draft document and may not even end up being officially
published. It may also be updated, replaced or obsoleted by other documents
at any time. It is inappropriate to cite this document as other than
@@ -342,27 +346,40 @@
<h1>Introduction</h1>
<p>
-The WebID protocol enables secure, efficient and maximally user friendly authentication on the Web.
+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.
-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>
+The identifier, known as the <tref>WebID</tref>, as well as the associated <tref>Profile Document</tref> have been defined in <a href="https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html">Web Identity and Discovery (WebID 1.0)</a> specification draft.</p>
<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.
+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 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.
+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.
</p>
-<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>
+<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.
+</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 organization of the specification and the conventions used throughout the document.</p>
+<p><a href="#introduction">This section</a> gives a high level overview of the WebID-TLS Protocol, and presents the organization 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>
+<p><a href="#the-webid-protocol">Section 3</a> on the WebID-TLS Protocol describes in detail how a server can authenticate a user.</p>
</section>
<section>
<h1>Terminology</h1>
<dl>
+
+<dt><tdef>WebID</tdef></dt>
+<dd>A WebID is a URI with an HTTP or HTTPS scheme which uniquely refers to 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 denoting the Profile Document.
+</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 referent of the <tref>WebID</tref> HTTP URI. 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.
+
+Any other serializations that intend to be used by <tref>WebID</tref> MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]].
+</dd>
+
<dt><tdef>Alice</tdef></dt>
<dd>Alice is an agent who owns a Server which runs a Service which Bob wishes to Access.</dd>
@@ -444,35 +461,20 @@
Indeed it can be signed by the server which hosts the <tref>WebID Profile</tref>, or it can even be self signed.
The Certificate MUST contain a <code>Subject Alternative Name</code> extension with at least one URI entry identifying the <tref>Subject</tref>.
This URI SHOULD be one of the URIs with a dereferenceable secure scheme, such as https:// . Dereferencing this URI should return a representation containing RDF data.
-For example, a certificate identifying the WebID URI <code>https://bob.example/profile#me</code> would contain the following:
+For example, a certificate identifying the <tref>WebID</tref> <code>https://bob.example/profile#me</code> would contain the following:
<pre class="example">
X.509v3 extensions:
...
X509v3 Subject Alternative Name:
URI:https://bob.example/profile#me
</pre>
-And it would have a <tref>WebID Profile</tref> at <code>https://bob.example/profile</code>
-Such a URI is known as a <tref>WebID</tref>.
-</dd>
-
-<dt><tdef>WebID</tdef></dt>
-<dd>A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions. The WebID should be a URI which when dereferenced returns a representation whose description uniquely identifies the Agent who is the controller of a public key. In our example the WebID refers to <tref>Bob</tref>. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in the document refered to by the WebID URL without the #tag .</dd>
+And it would have a <tref>WebID Profile</tref> at <code>https://bob.example/profile</code>.
</dd>
<dt><tdef>Public Key</tdef></dt>
<dd>A cryptographic key that can be published and can be used to verify the possession of a private key. A public
key is always included in a <tref>WebID Certificate</tref>.</dd>
-<dt><tdef>WebID Profile</tdef> or <tdef>Profile Page</tdef></dt>
-<dd>
-A structured document asserting the relationship between the Subject (identified by his WebID) and his <tref>Public Key</tref>s using relationships as defined by the Resource Description Framework [[RDF-CONCEPTS]] and published at the URL location of the Subject's WebID.
-Dereferencing the <tref>WebID</tref> should return the Profile Page in one of a number of formats.
-The Server MUST publish the document in at least the RDFa [[!RDFA-CORE]] serialization format or in Turtle [[!TURTLE-TR]].
-The document may be published in a number of other RDF serialization formats, such as RDF/XML [[!RDF-PRIMER]], or N3 [[!N3]].
-Any other serializations that intend to be used by the WebID Protocol MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]].
-<p class="issue">Most profiles are currently written out in either of those formats. Whether or not RDFa 1.1, both either serialization of RDF should be required serialization formats in the specification is currently under heavy debate and is open to change. </p>
-</dd>
-
</dl>
</section>
@@ -522,7 +524,7 @@
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 WebID can be <code>https://bob.example/profile#me</code></p>
+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.
@@ -530,7 +532,7 @@
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>
+following certificate as an output of the OpenSSL program.</p>
<pre class="example">
Certificate:
Data:
@@ -593,27 +595,28 @@
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 signature is now
+certificate and change the time and <tref>WebID</tref>. As a result the signature is now
false. A completely valid certificate should be generated to avoid nit-pickers
picking nits.</p>
<section class='normative'>
<h1>Creating a Certificate</h1>
-<p>Many tools exist to create a Certificate.
-Some <tref>Key Store</tref> 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 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 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 WebID 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.
+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>
<section class='normative'>
-<h1>Publishing the WebID Profile Document</h1>
+<h1>Publishing the Certificate data in a WebID Profile Document</h1>
+<!-- Update the image to contain only certificate data -->
-<p>The <tref>WebID Profile</tref> document MUST expose the relation between the <tref>WebID URI</tref> 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.
+<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 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 WebIDs 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>
@@ -621,11 +624,11 @@
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>
<p class="note">
-For reasons of interoperability, in order not to overburden the implementation and testing work of <tref>WebID Verifier</tref>s, and in order to provide a seamless experience for end users, of the many formats that can be publish at one location, it is established that at present publishers SHOULD publish their documents in at least one of RDFa [[!RDFA-CORE]] or [[!TURTLE-TR]] as these MUST be understood by <tref>Verification Agent</tref>s.
+For reasons of interoperability, in order not to overburden the implementation and testing work of <tref>WebID Verifier</tref>s, and in order to provide a seamless experience for end users, of the many formats that can be publish at one location, it is established that at present publishers MUST publish their documents as [[!TURTLE-TR]], but MAY publish them in other RDF serialization formats (e.g. [[!RDFA-CORE]]) which can then be requested through content negotiation.
If other formats grow in popularity, are implemented by verifiers, and gain community acceptance, these can be added to the list.
</p>
<p>
-Irrespective of whether content negotiation can or cannot be employed, if an HTML representation of the WebID profile is published, it is suggested that the provider uses the HTML <code><link></code> element to allow discovery of the various alternate representations of the graph which may be available:
+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:
</p>
<pre class="example">
@@ -640,7 +643,7 @@
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>
+<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.
@@ -651,16 +654,15 @@
<h2>Cryptographic Vocabulary</h2>
<p>The following properties SHOULD be used when conveying the relation between the
- <tref>Subject</tref> and his or her key.
-<tref>WebID Profile</tref> documents:</p>
+ <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>
<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
+ <dd>Used to associate a <tref>WebID</tref> URI with an RSAPublicKey. A <tref>WebID Profile</tref>
MUST contain at least one RSAPublicKey that is associated with the
- corresponding WebID URI.</dd>
+ corresponding <tref>WebID</tref> 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.
@@ -674,24 +676,7 @@
</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 of 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>
@@ -709,7 +694,7 @@
<#me> a foaf:Person;
foaf:name "Bob";
foaf:knows <https://example.edu/p/Alois#MSc>;
- foaf:weblog <http://bob.example/blog>;
+ foaf:img <http://bob.example/picture.jpg>;
cert:key [ a cert:RSAPublicKey;
rdfs:label "made on 23 November 2011 on my laptop";
cert:modulus "cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1"^^xsd:hexBinary;
@@ -721,7 +706,7 @@
<h1>RDFa HTML notation</h1>
<p>RDFa in HTML [[!RDFA-CORE]] is a way to markup HTML with relations that have a well defined semantics and
mapping to an RDF graph. 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.
+HTML. Here is just one example of what a <tref>WebID Profile</tref> could look like.
</p>
<pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
<!DOCTYPE html>
@@ -732,8 +717,7 @@
<body>
<!-- WebID HTML snippet. The prefix attribute above can be moved into the div below if needed -->
<div about="#me" typeof="foaf:Person">
- <p>My name is <span property="foaf:name">Bob</span> and I like to <a property="foaf:weblog" href="http://bob.example/blog">blog fun stuff</a>
- </p>
+ <p>My name is <span property="foaf:name">Bob</span> and this is my picture: <img property="img" src="http://bob.example/picture.jpg" title="Bob" alt="Bob" /></p>
<h2>My Good Friends</h2>
<ul>
<li property="foaf:knows" href="https://example.edu/p/Alois#MSc">Alois</li>
@@ -759,7 +743,7 @@
</body>
</html>
</pre>
-<p>If a WebID provider would rather prefer not to mark up his data in RDFa, but
+<p>If a <tref>WebID</tref> 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
in a machine readable format such as RDF/XML then a link from
the HTML to a machine readable format MAY be published
@@ -794,7 +778,7 @@
</section>
<section class='normative'>
-<h1>The WebID Protocol</h1>
+<h1>The <tref>WebID</tref> Authentication Protocol</h1>
<section class='normative'>
<h1>Authentication Sequence</h1>
@@ -802,8 +786,8 @@
<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.
+ 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.
</p>
@@ -820,7 +804,7 @@
</li>
<li>The Guard MUST request 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 summarized by the following steps:
<ol>
- <li>The guard requests the TLS agent to 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>The guard requests the TLS agent to make a Certificate Request to the client. The TLS layer does this. Because the WebID-TLS 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.
@@ -829,38 +813,38 @@
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>The <tref>WebID Certificate</tref> is then passed on to the <tref>Guard</tref> with the provision that the <tref>WebID</tref> 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>The <tref>Guard</tref> then MUST ask the <tref>Verification Agent</tref> to verify that the <tref>WebID</tref>s in the <tref>WebID Certificate</tref> do identify the agent who knows the given <tref>Public Key</tref>.
</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.
+ The <tref>Verification Agent</tref> may verify as many or as few <tref>WebID</tref>s 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>The WebID Verifier must get access to an up to date version of the WebID Profile Graph.
+ <li>The <tref>WebID Verifier</tref> must get access to an up to date version of the <tref>WebID Profile</tref> Graph.
<ol>
- <li>If the WebID Verifier has an up to date version of the graph in its graph cache then it can return it.</li>
- <li>Otherwise the <tref>WebID verifier</tref> MUST fetch an up to date version of the WebID Profile representation
+ <li>If the <tref>WebID Verifier</tref> has an up to date version of the graph in its graph cache then it can return it.</li>
+ <li>Otherwise the <tref>WebID verifier</tref> MUST fetch an up to date version of the <tref>WebID Profile</tref> representation
by dereferencing the URI, using the canonical method for dereferencing a URL of that scheme.
For an <code>https://...</code> <tref>WebID</tref> this would be done using the [[!HTTP-TLS]] protocol.
The dereferencing of the URI MAY use any representation caching mechanism it can to speed up the process.
- The returned representation is then transformed into an RDF graph [[!RDF-MT]] as specified in processing the WebID Profile .
+ The returned representation is then transformed into an RDF graph [[!RDF-MT]] as specified in processing the <tref>WebID Profile</tref> .
This graph may be then be cached to speed up future requests.
</li>
</ol>
</li>
<li>The graph returned in the previous step is then queried as explained in <a href="#verifying-the-webids">Verifying the WebIDs</a>.
- If the query is answered positively, then that WebID is verified.
+ If the query is answered positively, then that <tref>WebID</tref> is verified.
If the query fails and the graph was not up to date, then the Verifier MAY start again at point 5.1.2 by making
a request to an up to date graph.
</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.
+ <li>With the set of verified <tref>WebID</tref>s 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 <tref>WebID</tref> 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>
@@ -897,7 +881,7 @@
<p>Once the TLS connection has been setup, the application layer protocol interaction can start.
This could be an HTTP GET request on the protected resource for example.
-<p>If the protocol permits it, the Client can let the Application layer, and especially the <tref>Guard</tref> know that the client can authenticate with a WebID Certificate, and even if it wishes to do so. This may be useful both to allow the Server to know that it can request the client certificate, and also in order to make life easier for Robots that may find it a lot more convenient to be authenticated at the TLS layer.
+<p>If the protocol permits it, the Client can let the Application layer, and especially the <tref>Guard</tref> know that the client can authenticate with a <tref>WebID Certificate</tref>, and even if it wishes to do so. This may be useful both to allow the Server to know that it can request the client certificate, and also in order to make life easier for Robots that may find it a lot more convenient to be authenticated at the TLS layer.
</p>
<p class="issue">Bergi proposed a header for HTTP which could do this. Please summarise it. </p>
</section>
@@ -906,7 +890,7 @@
<section class='normative'>
<h2>Requesting the Client Certificate</h2>
-<p>TLS allows the server to request a Certificate from the Client using the <code>CertificateRequest</code> message [Section 7.4.4] of TLS v1.1 [[!RFC5246]]. Since WebID TLS authentication does not rely on CAs signing the certificate to verify the WebID Claims made therein, the Server does not need to restrict the certificate it receives by the CAs they were signed by. It can therefore leave the <code>certificate_authorities</code> field blank in the request. </p>
+<p>TLS allows the server to request a Certificate from the Client using the <code>CertificateRequest</code> message [Section 7.4.4] of TLS v1.1 [[!RFC5246]]. Since WebID TLS authentication does not rely on CAs signing the certificate to verify the <tref>WebID Claim</tref>s made therein, the Server does not need to restrict the certificate it receives by the CAs they were signed by. It can therefore leave the <code>certificate_authorities</code> field blank in the request. </p>
<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>
@@ -919,30 +903,30 @@
</section>
<section class='normative'>
<h2>Verifying the WebIDs</h2>
-<p>The <tref>Verification Agent</tref> is given a list of WebIDs associated with a public key. It needs to verify that the agent identified by that WebID is indeed the agent that controls the private key of the given public key. It does this by looking up the definition of the WebID. A WebID is a URI, and its meaning can be obtained by dereferencing it using the protocol indicated in its scheme. </p>
-<p>If we first consider WebIDs with fragment identifiers, we can explain the logic of this as follows. As is explained in the RFC defining URIs [[!RFC3986]]:
+<p>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 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 WebID containing a fragment identifier, one needs to dereference the resource referred to without the fragment identifier.
-This resource will describe the referent of the WebID using a syntax convertible to RDF triples.
-If the document returned states that the referent of the WebID is the agent that controls the private key of the given public key, then this is a definite description that can be considered to be a definition of the WebID: it gives its meaning.
+<p>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 WebID.
-An HTTPS WebID will therefore be a lot more trustworthy than an HTTP WebID by a factor of the likelihood of man in the middle attacks.</p>
-<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>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.
-The WebID <tref>Verification Agent</tref> MUST be able to parse documents in TURTLE [[!TURTLE-TR]], RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and RDFa [[!RDFA-CORE]].
+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">
-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.
+The <tref>Verification Agent</tref> MUST set the Accept-Header to request <code>text/turtle</code> with a higher priority than <code>text/html</code> and <code>application/rdf+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>
@@ -951,7 +935,7 @@
<h2>Verifying the WebID Claim</h2>
<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>
+To check a <tref>WebID Claim</tref> 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>
@@ -967,7 +951,7 @@
] .
}
</pre>
-<p>The variables to be replaced for each WebID claim are:</p>
+<p>The variables to be replaced for each <tref>WebID</tref> claim are:</p>
<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>
@@ -976,7 +960,7 @@
</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>?webid</code></td><td>should be replaced by the <tref>WebID</tref> 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 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>
@@ -1008,11 +992,11 @@
<section class='normative'>
<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.</p>
-<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.
+<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.
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 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 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.
+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.
</p>
@@ -1048,12 +1032,12 @@
<p><a href="https://dvcs.w3.org/hg/WebID/rev/dc93b6bbc538">2010-08-09</a>
Updates from WebID community: moved OpenID/OAuth sections to separate document,
switched to the URI terminology instead of URL, added "Creating the certificate"
-and "Publishing the WebID Profile document" sections with a WebID graph and
+and "Publishing the <tref>WebID Profile</tref> document" sections with a WebID graph and
serializations in Turtle and RDFa, improved SPARQL queries using literal
notation with cert datatypes, updated list of contributors,
and many other fixes.</p>
<p><a href="https://dvcs.w3.org/hg/WebID/rev/4aef27947dec">2010-07-25</a>
-Added WebID Profile section.</p>
+Added <tref>WebID Profile</tref> section.</p>
<p><a href="https://dvcs.w3.org/hg/WebID/rev/805d44635286">2010-07-18</a>
Updates from WebID community related to RDF/XML support, authentication sequence
corrections, abstract and introduction updates.</p>