--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/spec/drafts/ED-webid-20111212/index.html Mon Dec 12 13:21:18 2011 -0500
@@ -0,0 +1,1323 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML+RDFa 1.0//EN' 'http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd'>
+<html dir="ltr" about="" property="dcterms:language" content="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:dcterms='http://purl.org/dc/terms/' xmlns:bibo='http://purl.org/ontology/bibo/' xmlns:foaf='http://xmlns.com/foaf/0.1/' xmlns:xsd='http://www.w3.org/2001/XMLSchema#'>
+<head>
+ <title>WebID 1.0</title>
+ <meta content="text/html;charset=utf-8" http-equiv="Content-Type" />
+
+<!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+
+<style type="text/css">
+code { font-family: monospace; }
+
+span.hilite { color: red; /* font-weight: bold */ }
+
+li p { margin-top: 0.3em;
+ margin-bottom: 0.3em; }
+
+div.explanation { background-color: #ADD8E6;
+ width: 80%;
+ margin: 12px; padding: 8px; }
+div.explanation li { margin-top: 8px; }
+div.explanation dd { margin: 4px; }
+
+.adef {
+ font-family: monospace;
+ font-weight: bold;
+ color: #ff4500 !important;
+}
+
+.aref {
+ font-family: monospace;
+ font-weight: bold;
+ color: #ff4500 !important;
+}
+
+span.entity { color: red; }
+
+span.element { color: green; }
+</style>
+
+
+
+<!-- <script src='/ReSpec.js/js/respec.js' class='remove'></script> -->
+
+
+ <style type="text/css">
+/*****************************************************************
+ * ReSpec CSS
+ * Robin Berjon (robin at berjon dot com)
+ * v0.05 - 2009-07-31
+ *****************************************************************/
+
+
+/* --- INLINES --- */
+em.rfc2119 {
+ text-transform: lowercase;
+ font-variant: small-caps;
+ font-style: normal;
+ color: #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+ border: none;
+}
+
+dfn {
+ font-weight: bold;
+}
+
+a.internalDFN {
+ color: inherit;
+ border-bottom: 1px solid #99c;
+ text-decoration: none;
+}
+
+a.externalDFN {
+ color: inherit;
+ border-bottom: 1px dotted #ccc;
+ text-decoration: none;
+}
+
+a.bibref {
+ text-decoration: none;
+}
+
+code {
+ color: #ff4500;
+}
+
+
+/* --- WEB IDL --- */
+pre.idl {
+ border-top: 1px solid #90b8de;
+ border-bottom: 1px solid #90b8de;
+ padding: 1em;
+ line-height: 120%;
+}
+
+pre.idl::before {
+ content: "WebIDL";
+ display: block;
+ width: 150px;
+ background: #90b8de;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+.idlType {
+ color: #ff4500;
+ font-weight: bold;
+ text-decoration: none;
+}
+
+/*.idlModule*/
+/*.idlModuleID*/
+/*.idlInterface*/
+.idlInterfaceID, .idlDictionaryID {
+ font-weight: bold;
+ color: #005a9c;
+}
+
+.idlSuperclass {
+ font-style: italic;
+ color: #005a9c;
+}
+
+/*.idlAttribute*/
+.idlAttrType, .idlFieldType, .idlMemberType {
+ color: #005a9c;
+}
+.idlAttrName, .idlFieldName, .idlMemberName {
+ color: #ff4500;
+}
+.idlAttrName a, .idlFieldName a, .idlMemberName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlMethod*/
+.idlMethType {
+ color: #005a9c;
+}
+.idlMethName {
+ color: #ff4500;
+}
+.idlMethName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlParam*/
+.idlParamType {
+ color: #005a9c;
+}
+.idlParamName {
+ font-style: italic;
+}
+
+.extAttr {
+ color: #666;
+}
+
+/*.idlConst*/
+.idlConstType {
+ color: #005a9c;
+}
+.idlConstName {
+ color: #ff4500;
+}
+.idlConstName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlException*/
+.idlExceptionID {
+ font-weight: bold;
+ color: #c00;
+}
+
+.idlTypedefID, .idlTypedefType {
+ color: #005a9c;
+}
+
+.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
+ color: #c00;
+ font-weight: normal;
+}
+
+.excName a {
+ font-family: monospace;
+}
+
+.idlRaises a.idlType, .excName a.idlType {
+ border-bottom: 1px dotted #c00;
+}
+
+.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
+ width: 45px;
+ text-align: center;
+}
+.excGetSetTrue, .prmNullTrue, .prmOptTrue { color: #0c0; }
+.excGetSetFalse, .prmNullFalse, .prmOptFalse { color: #c00; }
+
+.idlImplements a {
+ font-weight: bold;
+}
+
+dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
+ margin-left: 2em;
+}
+
+.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
+ font-weight: normal;
+}
+
+.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
+ font-weight: bold;
+ color: #000;
+ font-family: monospace;
+}
+
+.attributes dt code, .fields dt code, .dictionary-members dt code {
+ background: #ffffd2;
+}
+
+.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
+ color: #005a9c;
+ background: transparent;
+ font-family: inherit;
+ font-weight: normal;
+ font-style: italic;
+}
+
+.methods dt code {
+ background: #d9e6f8;
+}
+
+.constants dt code {
+ background: #ddffd2;
+}
+
+.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
+ margin-bottom: 1em;
+}
+
+table.parameters, table.exceptions {
+ border-spacing: 0;
+ border-collapse: collapse;
+ margin: 0.5em 0;
+ width: 100%;
+}
+table.parameters { border-bottom: 1px solid #90b8de; }
+table.exceptions { border-bottom: 1px solid #deb890; }
+
+.parameters th, .exceptions th {
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+ font-family: initial;
+ font-weight: normal;
+ text-shadow: #666 1px 1px 0;
+}
+.parameters th { background: #90b8de; }
+.exceptions th { background: #deb890; }
+
+.parameters td, .exceptions td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+ vertical-align: top;
+}
+
+.parameters tr:first-child td, .exceptions tr:first-child td {
+ border-top: none;
+}
+
+.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
+ width: 100px;
+}
+
+.parameters td.prmType {
+ width: 120px;
+}
+
+table.exceptions table {
+ border-spacing: 0;
+ border-collapse: collapse;
+ width: 100%;
+}
+
+/* --- TOC --- */
+.toc a {
+ text-decoration: none;
+}
+
+a .secno {
+ color: #000;
+}
+
+/* --- TABLE --- */
+table.simple {
+ border-spacing: 0;
+ border-collapse: collapse;
+ border-bottom: 3px solid #005a9c;
+}
+
+.simple th {
+ background: #005a9c;
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+}
+
+.simple th[scope="row"] {
+ background: inherit;
+ color: inherit;
+ border-top: 1px solid #ddd;
+}
+
+.simple td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+ background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+ margin-top: 0;
+}
+
+.section dd > p:last-child {
+ margin-bottom: 0;
+}
+
+.section dd {
+ margin-bottom: 1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+ margin-bottom: 0;
+}
+
+/* --- EXAMPLES --- */
+pre.example {
+ border-top: 1px solid #ff4500;
+ border-bottom: 1px solid #ff4500;
+ padding: 1em;
+ margin-top: 1em;
+}
+
+pre.example::before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ background: #ff4500;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+/* --- EDITORIAL NOTES --- */
+.issue {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+}
+
+.issue::before {
+ content: "Issue";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.note {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #e2fff0;
+}
+
+.note::before {
+ content: "Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+/* --- Best Practices --- */
+div.practice {
+ border: solid #bebebe 1px;
+ margin: 2em 1em 1em 2em;
+}
+
+span.practicelab {
+ margin: 1.5em 0.5em 1em 1em;
+ font-weight: bold;
+ font-style: italic;
+}
+
+span.practicelab { background: #dfffff; }
+
+span.practicelab {
+ position: relative;
+ padding: 0 0.5em;
+ top: -1.5em;
+}
+
+p.practicedesc {
+ margin: 1.5em 0.5em 1em 1em;
+}
+
+@media screen {
+ p.practicedesc {
+ position: relative;
+ top: -2em;
+ padding: 0;
+ margin: 1.5em 0.5em -1em 1em;
+ }
+}
+
+/* --- SYNTAX HIGHLIGHTING --- */
+pre.sh_sourceCode {
+ background-color: white;
+ color: black;
+ font-style: normal;
+ font-weight: normal;
+}
+
+pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; } /* language keywords */
+pre.sh_sourceCode .sh_type { color: #666; } /* basic types */
+pre.sh_sourceCode .sh_usertype { color: teal; } /* user defined types */
+pre.sh_sourceCode .sh_string { color: red; font-family: monospace; } /* strings and chars */
+pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; } /* regular expressions */
+pre.sh_sourceCode .sh_specialchar { color: #ffc0cb; font-family: monospace; } /* e.g., \n, \t, \\ */
+pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; } /* comments */
+pre.sh_sourceCode .sh_number { color: purple; } /* literal numbers */
+pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; } /* e.g., #include, import */
+pre.sh_sourceCode .sh_symbol { color: blue; } /* e.g., *, + */
+pre.sh_sourceCode .sh_function { color: black; font-weight: bold; } /* function calls and declarations */
+pre.sh_sourceCode .sh_cbracket { color: red; } /* block brackets (e.g., {, }) */
+pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; } /* TODO and FIXME */
+
+/* Predefined variables and functions (for instance glsl) */
+pre.sh_sourceCode .sh_predef_var { color: #00008B; }
+pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }
+
+/* for OOP */
+pre.sh_sourceCode .sh_classname { color: teal; }
+
+/* line numbers (not yet implemented) */
+pre.sh_sourceCode .sh_linenum { display: none; }
+
+/* Internet related */
+pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }
+
+/* for ChangeLog and Log files */
+pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
+pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
+pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }
+
+/* for Prolog, Perl... */
+pre.sh_sourceCode .sh_variable { color: #006400; }
+
+/* for LaTeX */
+pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
+pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
+pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
+pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
+pre.sh_sourceCode .sh_argument { color: #006400; }
+pre.sh_sourceCode .sh_optionalargument { color: purple; }
+pre.sh_sourceCode .sh_math { color: orange; }
+pre.sh_sourceCode .sh_bibtex { color: blue; }
+
+/* for diffs */
+pre.sh_sourceCode .sh_oldfile { color: orange; }
+pre.sh_sourceCode .sh_newfile { color: #006400; }
+pre.sh_sourceCode .sh_difflines { color: blue; }
+
+/* for css */
+pre.sh_sourceCode .sh_selector { color: purple; }
+pre.sh_sourceCode .sh_property { color: blue; }
+pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }
+
+/* other */
+pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
+pre.sh_sourceCode .sh_paren { color: red; }
+pre.sh_sourceCode .sh_attribute { color: #006400; }
+
+</style><link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css" charset="utf-8" /></head>
+ <body style="display: inherit;"><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a></p><h1 id="title" class="title" property="dcterms:title">WebID 1.0</h1><h2 id="subtitle" property="bibo:subtitle">Web Identification and Discovery</h2><h2 content="2011-12-12T18:14:25+0000" datatype="xsd:dateTime" property="dcterms:issued" id="w3c-editor-s-draft-12-december-2011"><acronym title="World Wide Web Consortium">W3C</acronym> Editor's Draft 12 December 2011</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111212">http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111212</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111212">http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111212</a></dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-2011-11-23/" rel="dcterms:replaces">http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-2011-11-23/</a></dd><dt>Editors:</dt><dd rel="bibo:editor"><span typeof="foaf:Person"><a href="http://bblfish.net/" content="Henry Story" property="foaf:name" rel="foaf:homepage">Henry Story</a> <span class="ed_mailto"><a href="mailto:henry.story@bblfish.net" rel="foaf:mbox">henry.story@bblfish.net</a></span> </span>
+</dd>
+<dd rel="bibo:editor"><span typeof="foaf:Person"><span property="foaf:name">Stéphane Corlosquet</span>, <a href="http://massgeneral.org/" rel="foaf:workplaceHomepage">Massachusetts General Hospital</a> <span class="ed_mailto"><a href="mailto:scorlosquet@gmail.com" rel="foaf:mbox">scorlosquet@gmail.com</a></span> </span>
+</dd>
+<dt>Authors:</dt><dd rel="dcterms:contributor"><span typeof="foaf:Person"><span property="foaf:name">Manu Sporny</span>, <a href="http://blog.digitalbazaar.com/" rel="foaf:workplaceHomepage">Digital Bazaar, Inc.</a> <span class="ed_mailto"><a href="mailto:msporny@digitalbazaar.com" rel="foaf:mbox">msporny@digitalbazaar.com</a></span> </span>
+</dd>
+<dd rel="dcterms:contributor"><span typeof="foaf:Person"><a href="http://tobyinkster.co.uk/" content="Toby Inkster" property="foaf:name" rel="foaf:homepage">Toby Inkster</a></span>
+</dd>
+<dd rel="dcterms:contributor"><span typeof="foaf:Person"><a href="http://bblfish.net/" content="Henry Story" property="foaf:name" rel="foaf:homepage">Henry Story</a></span>
+</dd>
+<dd rel="dcterms:contributor"><span typeof="foaf:Person"><a href="http://blog.distributedmatter.net/" content="Bruno Harbulot" property="foaf:name" rel="foaf:homepage">Bruno Harbulot</a></span>
+</dd>
+<dd rel="dcterms:contributor"><span typeof="foaf:Person"><a href="http://trialox.org/" content="Reto Bachmann-Gmür" property="foaf:name" rel="foaf:homepage">Reto Bachmann-Gmür</a></span>
+</dd>
+</dl><p>This document is also available in this non-normative format: <a href="http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20110210/diff-20100809.html">Diff from previous Editors Draft</a>.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright" rel="license">Copyright</a> © 2010-2011 <span rel="dcterms:publisher"><span typeof="foaf:Organization"><a href="http://www.w3.org/" content="World Wide Web Consotrium" property="foaf:name" rel="foaf:homepage"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup></span></span> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr /></div>
+ <div id="abstract" class="introductory section" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" about="#abstract"><h2>Abstract</h2>
+
+<p>A global distributed Social Web requires that each person be able to control their identity, that this identity be linkable across sites - placing each person in a Web of relationships - and that it be possible to authenticate globally with such identities. By making distributed authentication easy one can allow everybody to protect their resources and enable their preferred privacy settings.</p>
+<p>This specification outlines a simple universal identification mechanism that is distributed, openly extensible, improves privacy, security and control over how each person can identify themselves in order to allow fine grained access control to their information on the Web.
+It does this by applying the best practices of Web Architecture whilst building on well established widely deployed protocols and standards including HTML, XHTML, URIs, HTTP, TLS, X509 Certificates, and RDF Semantics.
+</p>
+
+<div typeof="bibo:Chapter" about="#how-to-read-this-document" class="section">
+<h3 id="how-to-read-this-document">How to Read this Document</h3>
+
+<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
+<a href="http://en.wikipedia.org/wiki/Public_key_cryptography">public key cryptography</a>
+and RDF [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-PRIMER">RDF-PRIMER</a></cite>] is necessary to understand how
+to implement this specification. WebID uses a number of specific technologies
+like HTTP over TLS [<cite><a class="bibref" rel="biblioentry" href="#bib-HTTP-TLS">HTTP-TLS</a></cite>], X.509 certificates [<cite><a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a></cite>],
+RDF/XML [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-SYNTAX-GRAMMAR">RDF-SYNTAX-GRAMMAR</a></cite>] and XHTML+RDFa [<cite><a class="bibref" rel="biblioentry" href="#bib-XHTML-RDFA">XHTML-RDFA</a></cite>].</p>
+
+<p>A general <a href="#introduction">Introduction</a> is provided for all that
+would like to understand why this specification is necessary to simplify usage
+of the Web.</p>
+
+<p>The terms used throughout this specification are listed in the section
+titled <a href="#terminology">Terminology</a>.</p>
+
+<p>Developers that are interested in implementing this specification will be
+most interested in the sections titled
+<a href="#authentication-sequence">Authentication Sequence</a> and
+<a href="#authentication-sequence-details">Authentication Sequence Details</a>.</p>
+
+</div>
+</div><div class="introductory section" id="sotd" typeof="bibo:Chapter" about="#sotd"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p>
+
+<!-- <p>This document has been reviewed by W3C Members, by software
+developers, and by other W3C groups and interested parties, and is
+endorsed by the Director as a W3C Recommendation. It is a stable
+document and may be used as reference material or cited from another
+document. W3C's role in making the Recommendation is to draw attention
+to the specification and to promote its widespread deployment. This
+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/"><acronym title="World Wide Web Consortium">W3C</acronym> WebID Incubator 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
+work in progress.
+The source code for this document is available at the following
+URI: <a href="https://dvcs.w3.org/hg/WebID">https://dvcs.w3.org/hg/WebID</a>
+
+<p>This document was published by the <a href="http://www.w3.org/2005/Incubator/webid/">WebID XG</a> as an Editor's Draft. If you wish to make comments regarding this document, please send them to <a href="mailto:public-xg-webid@w3.org">public-xg-webid@w3.org</a> (<a href="mailto:public-xg-webid-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-xg-webid/">archives</a>). All feedback is welcome.</p><p>Publication as an Editor's Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a rel="disclosure" href="http://www.w3.org/2004/01/pp-impl/46065/status">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" typeof="bibo:Chapter" about="#toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#outline" class="tocxref"><span class="secno">1.1 </span>Outline</a></li><li class="tocline"><a href="#terminology" class="tocxref"><span class="secno">1.2 </span>Terminology</a></li><li class="tocline"><a href="#namespaces" class="tocxref"><span class="secno">1.3 </span>Namespaces</a></li></ul></li><li class="tocline"><a href="#preconditions" class="tocxref"><span class="secno">2. </span>Preconditions</a><ul class="toc"><li class="tocline"><a href="#the-certificate" class="tocxref"><span class="secno">2.1 </span>The certificate</a><ul class="toc"><li class="tocline"><a href="#creating-a-certificate" class="tocxref"><span class="secno">2.1.1 </span>Creating a Certificate</a></li></ul></li><li class="tocline"><a href="#publishing-the-webid-profile-document" class="tocxref"><span class="secno">2.2 </span>Publishing the WebID Profile Document</a><ul class="toc"><li class="tocline"><a href="#turtle" class="tocxref"><span class="secno">2.2.1 </span>Turtle</a></li><li class="tocline"><a href="#rdfa-html-notation" class="tocxref"><span class="secno">2.2.2 </span>RDFa HTML notation</a></li><li class="tocline"><a href="#in-rdf-xml" class="tocxref"><span class="secno">2.2.3 </span>In RDF/XML</a></li><li class="tocline"><a href="#in-portable-contacts-format-using-grddl" class="tocxref"><span class="secno">2.2.4 </span>In Portable Contacts format using GRDDL</a></li></ul></li><li class="tocline"><a href="#disabling-a-webid-certificate" class="tocxref"><span class="secno">2.3 </span>Disabling a WebID Certificate</a></li></ul></li><li class="tocline"><a href="#the-webid-protocol" class="tocxref"><span class="secno">3. </span>The WebID Protocol</a><ul class="toc"><li class="tocline"><a href="#authentication-sequence" class="tocxref"><span class="secno">3.1 </span>Authentication Sequence</a></li><li class="tocline"><a href="#authentication-sequence-details" class="tocxref"><span class="secno">3.2 </span>Authentication Sequence Details</a><ul class="toc"><li class="tocline"><a href="#initiating-a-tls-connection" class="tocxref"><span class="secno">3.2.1 </span>Initiating a TLS Connection</a></li><li class="tocline"><a href="#connecting-at-the-application-layer" class="tocxref"><span class="secno">3.2.2 </span>Connecting at the Application Layer</a></li><li class="tocline"><a href="#requesting-the-client-certificate" class="tocxref"><span class="secno">3.2.3 </span>Requesting the Client Certificate</a></li><li class="tocline"><a href="#verifying-the-webids" class="tocxref"><span class="secno">3.2.4 </span>Verifying the WebIDs</a><ul class="toc"><li class="tocline"><a href="#processing-the-webid-profile" class="tocxref"><span class="secno">3.2.4.1 </span>Processing the WebID Profile</a></li><li class="tocline"><a href="#verifying-the-webid-claim" class="tocxref"><span class="secno">3.2.4.2 </span>Verifying the WebID Claim</a></li><li class="tocline"><a href="#authorization" class="tocxref"><span class="secno">3.2.4.3 </span>Authorization</a></li></ul></li><li class="tocline"><a href="#the-webid-profile" class="tocxref"><span class="secno">3.2.5 </span>The WebID Profile</a><ul class="toc"><li class="tocline"><a href="#personal-information" class="tocxref"><span class="secno">3.2.5.1 </span>Personal Information</a></li><li class="tocline"><a href="#cryptographic-details" class="tocxref"><span class="secno">3.2.5.2 </span>Cryptographic Details</a></li></ul></li></ul></li></ul></li><li class="tocline"><a href="#history" class="tocxref"><span class="secno">A. </span>Change History</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">B. </span>Acknowledgments</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></div>
+
+
+
+<div class="informative section" id="introduction" typeof="bibo:Chapter" about="#introduction">
+
+<!-- OddPage -->
+<h2><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
+
+<p>
+The WebID protocol enables secure, efficient and maximally user friendly authentication on the Web.
+It enables people to authenticate onto any site by simply clicking on one of the certificates proposed to them by their browser.
+These certificates can be created by any Web Site for their users in one click.
+The identifier, known as the <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a>, is a URI whose sense can be found in the associated <a class="tref internalDFN" title="Profile_Page" href="#dfn-profile_page">Profile Page</a>, a type of web page that any Social Network user is familiar with.</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.
+Such a web of trust can then be used by a <a class="tref internalDFN" title="Service" href="#dfn-service">Service</a> to make authorization decisions, by allowing access to resource depending on the properties of an agent, such that the he is known by some relevant people, works at a given company, is a family member, is part of some group, ...</p>
+<p>
+The WebID protocol specifies how a <a class="tref internalDFN" title="Service" href="#dfn-service">Service</a> can authenticate a user after requesting his <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a> without needing to rely on this being signed by a well known Certificate Authority. This is done by dereferencing the <a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a>, and checking if it describes the user as being in control of the the private key related to the <a class="tref internalDFN" title="Public_Key" href="#dfn-public_key">Public Key</a> published in the <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a> she 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>
+<div id="outline" typeof="bibo:Chapter" about="#outline" class="section">
+<h3><span class="secno">1.1 </span>Outline</h3>
+<p>This specification is divided in the following sections.</p>
+<p><a href="#introduction">This section</a> gives a high level overview of the WebID Protocol, and presents the organisation of the specification and the conventions used throughout the document.</p>
+<p><a href="#preconditions">Section 2</a> lists the preconditions that need to be in place for any authentication sequence to be successful: which include the creation of a <a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a> and the creation of a <a class="tref internalDFN" title="WebID_Certificate" href="#dfn-webid_certificate">WebID Certificate</a></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>
+</div>
+<div id="terminology" typeof="bibo:Chapter" about="#terminology" class="section">
+<h3><span class="secno">1.2 </span>Terminology</h3>
+<dl>
+<dt><dfn title="Alice" id="dfn-alice">Alice</dfn></dt>
+<dd>Alice is an agent who owns a Server which runs a Service which Bob wishes to Access</dd>
+
+<dt><dfn title="Bob" id="dfn-bob">Bob</dfn></dt>
+<dd>Bob is an agent who uses a <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> to connect to <a class="tref internalDFN" title="Alice" href="#dfn-alice">Alice</a>'s Service, and who is responsible for the private key the <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> uses to authenticate to <a class="tref internalDFN" title="Service" href="#dfn-service">Service</a>s.
+If he notices the private key was compromised he needs to take action to disable the public key.
+</dd>
+<dt><dfn title="Subject" id="dfn-subject">Subject</dfn></dt>
+<dd>The Subject is the Agent that is identified by the <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a>.
+When used legally it is the Subject who wishes to authenticate to a <a class="tref internalDFN" title="Service" href="#dfn-service">Service</a>.
+We will name him <a class="tref internalDFN" title="Bob" href="#dfn-bob">Bob</a> throughout this document to improve readability.
+The Subject is distinct from the <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> which is used to connect to the <a class="tref internalDFN" title="Server" href="#dfn-server">Server</a>.
+</dd>
+<dt><dfn title="Client" id="dfn-client">Client</dfn></dt>
+<dd>The Client initiates a request to a Service listening on a specific port using a given protocol on a given Server. It can request authentication credentials from a <a class="tref internalDFN" title="Key_Chain" href="#dfn-key_chain">Key Chain</a> to send to a server
+</dd>
+
+<dt><dfn title="Key_Chain" id="dfn-key_chain">Key Chain</dfn> agent</dt>
+<dd>A Key Chain agent can return certificates to authorized <a class="tref" title="Clients">Clients</a> and can sign cryptographic tokens with the corresponding key. This protocol does not specify where that agent is: it could be that the <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> contains his own Key Chain or it could be that the Key Chain is a separate process on the Operating System.</dd>
+
+<dt><dfn title="Server" id="dfn-server">Server</dfn></dt>
+<dd>A Server is a machine contactable at a domain name or IP address that hosts a number of globally accessible Services.</dd>
+
+<dt><dfn title="Service" id="dfn-service">Service</dfn></dt>
+<dd>A Service is a an agent listening for requests at a given IP address on a given Server</dd>
+
+<dt><dfn title="TLS_Service" id="dfn-tls_service">TLS Service</dfn></dt>
+<dd>A TLS Service is a transport level service listening on the <a class="tref internalDFN" title="Service" href="#dfn-service">Service</a> port.
+It secures the transport layer before passing messages to the Application layer <a class="tref internalDFN" title="Service" href="#dfn-service">Service</a> itself.
+The TLS protocol [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC5246">RFC5246</a></cite>] is applied to incoming connections: it identifies the server to the client, securing the channel and is able to request authentication credentials from the <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> if needed.
+Server Credentials and Client credentials traditionally take the form of X509 Certificates containing a public key.
+The TLS protocol enables the TLS Service to verify that the <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> controls the private key of the <a class="tref internalDFN" title="Public_Key" href="#dfn-public_key">Public Key</a> published in the certificate.
+Trust decisions on other attributes of the <a class="tref internalDFN" title="Subject" href="#dfn-subject">Subject</a> published in the Certificate - such as his name - are traditionally based on the trust in the Agent that signed the Certificate - known as a <a class="tref internalDFN" title="Certificate_Authority" href="#dfn-certificate_authority">Certificate Authority</a>.
+</dd>
+<dt><dfn title="Certificate" id="dfn-certificate">Certificate</dfn></dt><dt>
+</dt><dd>A Certificate is a document that affirms statements about a <a class="tref internalDFN" title="Subject" href="#dfn-subject">Subject</a> such as its <a class="tref internalDFN" title="public_key" href="#dfn-public_key">public key</a> and its name, and that is signed by a <a class="tref internalDFN" title="Certificate_Authority" href="#dfn-certificate_authority">Certificate Authority</a> using the private key that corresponds to the public key published in its certificate. The Certificate Authority's own Certificate is self signed. Certificates used by TLS are traditionally X509 [<cite><a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a></cite>] Certificates. </dd>
+<dt><dfn title="Certificate_Authority" id="dfn-certificate_authority">Certificate Authority</dfn> (<dfn title="CA" id="dfn-ca">CA</dfn>)</dt>
+<dd>
+A Certificate Authority is a Subject that signs <a class="tref" title="Certificates">Certificates</a>.
+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.
+<a class="tref internalDFN" title="Service" href="#dfn-service">Service</a>s usually identify themselves with Certificates signed by well known and widely deployed CAs available in all agents.
+</dd>
+<dt><dfn title="TLS-Light_Service" id="dfn-tls-light_service">TLS-Light Service</dfn></dt>
+<dd>A TLS-Light Service is a standard TLS Service, except that it does not do CA Based Client Certificate Authentication.
+If on requesting a Certificate from a Client it receives one, it simply verifies that the <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> knows the private key of the public key published in the Certificate it received.
+Verification of attributes in the certificate is left to other services such as the <a class="tref internalDFN" title="WebID_Verifier" href="#dfn-webid_verifier">WebID Verifier</a>.
+</dd>
+
+<dt><dfn title="Guard" id="dfn-guard">Guard</dfn></dt><dt>
+</dt><dd>A guard is an agent, usually on the <a class="tref internalDFN" title="Server" href="#dfn-server">Server</a> that can look at a request from the <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> and decide if it needs Authentication by looking at the Access control Rules.
+If it needs Authentication it can request it, and it can use the <a class="tref internalDFN" title="WebID_Verifier" href="#dfn-webid_verifier">WebID Verifier</a> to complete identity checks.
+Finally it can grant or deny access.
+</dd>
+
+<dt><dfn title="Verification_Agent" id="dfn-verification_agent">Verification Agent</dfn> or <dfn title="WebID_Verifier" id="dfn-webid_verifier">WebID Verifier</dfn></dt>
+<dd>A WebID Verifier takes a <a class="tref internalDFN" title="WebID_Certificate" href="#dfn-webid_certificate">WebID Certificate</a> and verifies that the <a class="tref internalDFN" title="Subject" href="#dfn-subject">Subject</a> of the Certificate is indeed identified by the <code>Subject Alternative Name</code> <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a> published there.
+This is usually done, because the <a class="tref" title="TLS_Service_Light">TLS Service Light</a> did not verify the SAN using a <a class="tref internalDFN" title="Certificate_Authority" href="#dfn-certificate_authority">Certificate Authority</a> signature.
+But it can also be done to verify that the <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a> is still valid.
+</dd>
+
+<dt><dfn title="WebID_Certificate" id="dfn-webid_certificate">WebID Certificate</dfn></dt>
+<dd>An X.509 [<cite><a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a></cite>] <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a> that will identify an Agent using a <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a>.
+The Certificate need not be signed by a well known Certificate Authority.
+Indeed it can be signed by the server which hosts the certificate, or it can even be self signed.
+The Certificate <em class="rfc2119" title="must">must</em> contain a <code>Subject Alternative Name</code> extension with at least one URI entry identifying the <a class="tref internalDFN" title="Subject" href="#dfn-subject">Subject</a>.
+This URI <em class="rfc2119" title="should">should</em> 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:
+<pre class="example">X509v3 extensions:
+ ...
+ X509v3 Subject Alternative Name:
+ URI:https://bob.example/profile#me</pre>
+And it would have a <a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a> at <code>https://bob.example/profile</code>
+Such a URI is known as a <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a>.
+</dd>
+
+<dt><dfn title="WebID" id="dfn-webid">WebID</dfn></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 as the controller of a public key. In our example the WebID refers to Bob. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in the document.</dd>
+
+
+<dt><dfn title="Public_Key" id="dfn-public_key">Public Key</dfn></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 <a class="tref internalDFN" title="WebID_Certificate" href="#dfn-webid_certificate">WebID Certificate</a>.</dd>
+
+<dt><dfn title="WebID_Profile" id="dfn-webid_profile">WebID Profile</dfn> or <dfn title="Profile_Page" id="dfn-profile_page">Profile Page</dfn></dt>
+<dd>
+A structured document asserting the relationship between the Subject (identified by his WebID) and his <a class="tref internalDFN" title="Public_Key" href="#dfn-public_key">Public Key</a>s using relationships as defined by the Resource Description Framework [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-CONCEPTS">RDF-CONCEPTS</a></cite>] and published at the URL location of the Subject's WebID.
+Dereferencing the <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a> should return the Profile Document in one of a number of formats.
+The Server <em class="rfc2119" title="must">must</em> publish the document in at least the XHTML+RDFa 1.1 [<cite><a class="bibref" rel="biblioentry" href="#bib-XHTML-RDFA">XHTML-RDFA</a></cite>] serialization format or in RDF/XML [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-SYNTAX-GRAMMAR">RDF-SYNTAX-GRAMMAR</a></cite>].
+The document may be published in a number of other RDF serialization formats, such as N3 [<cite><a class="bibref" rel="biblioentry" href="#bib-N3">N3</a></cite>] or Turtle [<cite><a class="bibref" rel="biblioentry" href="#bib-TURTLE">TURTLE</a></cite>].
+Any serialisation <em class="rfc2119" title="must">must</em> be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [<cite><a class="bibref" rel="biblioentry" href="#bib-GRDDL-PRIMER">GRDDL-PRIMER</a></cite>].
+<p class="issue">Most profiles are currently written out in either of those formats. Whether or not XHTML+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>
+</div>
+
+<div class="normative section" id="namespaces" typeof="bibo:Chapter" about="#namespaces">
+<h3><span class="secno">1.3 </span>Namespaces</h3>
+<p>Examples assume the following namespace prefix bindings unless otherwise stated:</p>
+<table cellpadding="5" border="1" style="text-align: left; border-color: rgb(0, 0, 0); border-collapse: collapse;">
+ <thead>
+ <tr>
+ <th>Prefix</th>
+ <th>IRI</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>cert</code></td>
+ <td>http://www.w3.org/ns/auth/cert#</td>
+ </tr>
+
+ <tr>
+ <td><code>xsd</code></td>
+ <td>http://www.w3.org/2001/XMLSchema#</td>
+ </tr>
+ <tr>
+ <td><code>foaf</code></td>
+ <td>http://xmlns.com/foaf/0.1/</td>
+ </tr>
+ <tr>
+ <td><code>ex</code></td>
+ <td>https://bob.example/profile#</td>
+ </tr>
+ </tbody>
+</table>
+
+<p>The ex: namespace is a URI that refers to Bob's profile, where Bob is an imaginary character well known in security circles.</p>
+</div>
+</div>
+
+<div id="preconditions" typeof="bibo:Chapter" about="#preconditions" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">2. </span>Preconditions</h2>
+
+
+<div class="normative section" id="the-certificate" typeof="bibo:Chapter" about="#the-certificate">
+<h3><span class="secno">2.1 </span>The certificate</h3>
+
+<p>The <a class="tref internalDFN" title="Key_Chain" href="#dfn-key_chain">Key Chain</a> must have a <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a> 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 <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a> at this URI.</p>
+<p>For example, if a user Bob controls <code>https://bob.example/profile</code>,
+then his WebID can be <code>https://bob.example/profile#me</code></p>
+<p>When creating a certificate it is very important to 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 <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a> 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 <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a> 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>
+<pre class="example">Certificate:
+ Data:
+ Version: 3 (0x2)
+ Serial Number:
+ 5f:df:d6:be:2c:73:c1:fb:aa:2a:2d:23:a6:91:3b:5c
+ Signature Algorithm: sha1WithRSAEncryption
+ <span style="color: red">Issuer:</span> O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority
+ Validity
+ Not Before: Jun 8 14:16:14 2010 GMT
+ Not After : Jun 8 16:16:14 2010 GMT
+ <span style="color: red">Subject:</span> O=FOAF+SSL, OU=The Community Of Self Signers, CN=Bob (Personal)
+ Subject Public Key Info:
+<span style="color: red"> Public Key Algorithm:</span> rsaEncryption
+ <span style="color: red">Public-Key:</span> (2048 bit)
+ <span style="color: red">Modulus:</span>
+ 00:cb:24:ed:85:d6:4d:79:4b:69:c7:01:c1:86:ac:
+ c0:59:50:1e:85:60:00:f6:61:c9:32:04:d8:38:0e:
+ 07:19:1c:5c:8b:36:8d:2a:c3:2a:42:8a:cb:97:03:
+ 98:66:43:68:dc:2a:86:73:20:22:0f:75:5e:99:ca:
+ 2e:ec:da:e6:2e:8d:15:fb:58:e1:b7:6a:e5:9c:b7:
+ ac:e8:83:83:94:d5:9e:72:50:b4:49:17:6e:51:a4:
+ 94:95:1a:1c:36:6c:62:17:d8:76:8d:68:2d:de:78:
+ dd:4d:55:e6:13:f8:83:9c:f2:75:d4:c8:40:37:43:
+ e7:86:26:01:f3:c4:9a:63:66:e1:2b:b8:f4:98:26:
+ 2c:3c:77:de:19:bc:e4:0b:32:f8:9a:e6:2c:37:80:
+ f5:b6:27:5b:e3:37:e2:b3:15:3a:e2:ba:72:a9:97:
+ 5a:e7:1a:b7:24:64:94:97:06:6b:66:0f:cf:77:4b:
+ 75:43:d9:80:95:2d:2e:85:86:20:0e:da:41:58:b0:
+ 14:e7:54:65:d9:1e:cf:93:ef:c7:ac:17:0c:11:fc:
+ 72:46:fc:6d:ed:79:c3:77:80:00:0a:c4:e0:79:f6:
+ 71:fd:4f:20:7a:d7:70:80:9e:0e:2d:7b:0e:f5:49:
+ 3b:ef:e7:35:44:d8:e1:be:3d:dd:b5:24:55:c6:13:
+ 91:a1
+ <span style="color: red">Exponent:</span> 65537 (0x10001)
+ X509v3 extensions:
+ X509v3 Basic Constraints: critical
+ CA:FALSE
+ X509v3 Key Usage: critical
+ Digital Signature, Non Repudiation, Key Encipherment, Key Agreement
+ Netscape Cert Type:
+ SSL Client, S/MIME
+ X509v3 Subject Key Identifier:
+ 08:8E:A5:5B:AE:5D:C3:8B:00:B7:30:62:65:2A:5A:F5:D2:E9:00:FA
+ <span style="color: red">X509v3 Subject Alternative Name:</span> critical
+ <span style="color: red">URI:</span>https://bob.example/profile#me
+ Signature Algorithm: sha1WithRSAEncryption
+ cf:8c:f8:7b:b2:af:63:f0:0e:dc:64:22:e5:8a:ba:03:1e:f1:
+ ee:6f:2c:f5:f5:10:ad:4c:54:fc:49:2b:e1:0d:cd:be:3d:7c:
+ 78:66:c8:ae:42:9d:75:9f:2c:29:71:91:5c:29:5b:96:ea:e1:
+ e4:ef:0e:5c:f7:07:a0:1e:9c:bf:50:ca:21:e6:6c:c3:df:64:
+ 29:6b:d3:8a:bd:49:e8:72:39:dd:07:07:94:ac:d5:ec:85:b1:
+ a0:5c:c0:08:d3:28:2a:e6:be:ad:88:5e:2a:40:64:59:e7:f2:
+ 45:0c:b9:48:c0:fd:ac:bc:fb:1b:c9:e0:1c:01:18:5e:44:bb:
+ d8:b8</pre>
+<p class="issue">Should we formally require the Issuer to be
+O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority.
+This was discussed on the list as allowing servers to distinguish certificates
+that are foaf+SSL enabled from others. Will probably need some very deep TLS
+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
+false. A completely valid certificate should be generated to avoid nit-pickers
+picking nits.</p>
+<div class="normative section" id="creating-a-certificate" typeof="bibo:Chapter" about="#creating-a-certificate">
+<h4><span class="secno">2.1.1 </span>Creating a Certificate</h4>
+<p>Many tools exist to create a Certificate.
+Some keychains allow a user to create the Certificate directly with a friendly User Interface.
+But using a keychain on the client still requires the public key to be published on the server as detailed in the next section.
+It is possible to combine the creation of the key with its publication in one step in such a way as to allow the server to make the decision of what the WebID should be, by using the <a href="http://www.w3.org/TR/html5/the-button-element.html#the-keygen-element">HTML 5 keygen</a> element.
+This element can be placed in an HTML5 form, where on submitting the form, the browser asks the <a class="tref internalDFN" title="Key_Chain" href="#dfn-key_chain">Key Chain</a> to create a public and private key pair, and on receiving the public part of that keypair the Client can sends a keyrequest as part of the form to the <a class="tref internalDFN" title="Service" href="#dfn-service">Service</a>. The <a class="tref internalDFN" title="Service" href="#dfn-service">Service</a> can then create a <a class="tref internalDFN" title="WebID_Certificate" href="#dfn-webid_certificate">WebID Certificate</a> and return it to the <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> to pass onto the <a class="tref" title="KeyChain">KeyChain</a>. In that way the Server is in the position to best make the decisions of what the <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a> should say and what the WebID should be without the private key ever leaving the secure <a class="tref internalDFN" title="Key_Chain" href="#dfn-key_chain">Key Chain</a>. The user experience for this Certificate creation is a one click operation.
+</p></div>
+</div>
+
+<div class="normative section" id="publishing-the-webid-profile-document" typeof="bibo:Chapter" about="#publishing-the-webid-profile-document">
+<h3><span class="secno">2.2 </span>Publishing the WebID Profile Document</h3>
+
+<p>The <a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a> document <em class="rfc2119" title="must">must</em> expose the relation between the <a class="tref" title="WebID_URI">WebID URI</a> and the <a class="tref" title="Identification_Agent">Identification Agent</a>'s <a class="tref internalDFN" title="public_key" href="#dfn-public_key">public key</a>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 <a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a> document can be presented in a graphical notation as follows.</p>
+<img width="90%" src="img/WebIdGraph.jpg" alt="Web ID graph" />
+<p>The document can publish many more relations than are of interest to the WebID protocol, as shown in the above graph by the grayed out relations.
+For example Bob can publish a depiction or logo, so that sites he authenticates to can personalise the user experience. He can post links to people he knows, where those are have WebIDs published on other sites, in order to create a distributed Social Web.
+He can also publish relations to protected documents, where he keeps more information for people who authenticate, such as his friend Alois or his friends friends who may not yet know him personally, such as Alice.</p>
+<p>
+The protocol does not depend on any particular serialisation of the graph, provided that agents are able to parse that serialisation and obtain the graph automatically.
+Technologies such as GRDDL [<cite><a class="bibref" rel="biblioentry" href="#bib-GRDDL-PRIMER">GRDDL-PRIMER</a></cite>] for example permit any XML format to be transformed automatically to a graph of relations.
+Yet for reasons of interoperability is has been decided that the document <em class="rfc2119" title="must">must</em> be published at least in one of RDFa [XHTML-RDFA] or RDF/XML [RDF-SYNTAX-GRAMMAR].
+HTTP Content Negotiation [SWBP-VOCAB-PUB] can be employed to aid in publication and discovery of multiple distinct serialisations of the same graph at the same URL. </p>
+<p>
+Irrespective of whether content negotiation can or not be employed, if an HTML representation of the WebID profile is published, it is suggested that the provider uses the HTML <code><link></code> element to allow discovery of the various alternate representations of the graph which may be available:
+</p>
+
+<pre class="example"><html>
+<head>
+<link rel="alternate" type="application/rdf+xml" href="profile.rdf"/>
+<link rel="alternate" type="text/turtle" href="profile.ttl"/>
+...
+</head> ...</pre>
+<p>It is particularly useful to have one of the representations be in HTML or
+XHTML even if it is not marked up in RDFa as this allows people using a
+web browser to understand what the information at that URI represents.</p>
+<div class="normative section" id="turtle" typeof="bibo:Chapter" about="#turtle">
+<h4><span class="secno">2.2.1 </span>Turtle</h4>
+<p>A widely used format for writing RDF graphs by hand is the Turtle notation.
+It is easy to learn to use, is very handy for communicating over e-mail and on mailing lists, and can then be transformed into RDF/XML automatically.
+It is also very similar to the SPARQL query language.
+</p>
+<pre style="word-wrap: break-word; white-space: pre-wrap;" class="example">@prefix : <http://www.w3.org/ns/auth/cert#> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+@prefix foaf: <http://xmlns.com/foaf/0.1/> .
+@prefix bob: <https://bob.example/profile#> .
+@prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
+
+bob:me a foaf:Person;
+ foaf:name "Bob";
+ foaf:knows <https://example.edu/p/Alois#MSc>;
+ foaf:weblog <http://bob.example/blog>;
+ :key [ a :RSAPublicKey;
+ rdfs:label "made on 23 November 2011 on my laptop";
+ :modulus "cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1"^^xsd:hexBinary;
+ :exponent 65537 ;
+ ] .</pre>
+</div>
+<div id="rdfa-html-notation" typeof="bibo:Chapter" about="#rdfa-html-notation" class="section">
+<h4><span class="secno">2.2.2 </span>RDFa HTML notation</h4>
+<p>There are many ways of writing out the above graph using RDFa in
+HTML. Here is just one example of what a WebID profile could look like.</p>
+<pre style="word-wrap: break-word; white-space: pre-wrap;" class="example"><!DOCTYPE html PUBLIC "-//<acronym title="World Wide Web Consortium">W3C</acronym>//DTD XHTML+RDFa 1.0//EN"
+ "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" version="XHTML+RDFa 1.0" dir="ltr"
+ xmlns:cert="http://www.w3.org/ns/auth/cert#"
+ xmlns:foaf="http://xmlns.com/foaf/0.1/"
+ xmlns:xsd="http://www.w3.org/2001/XMLSchema#">
+<head>
+ <title>Welcome to Bob's Home Page</title>
+</head>
+<body>
+<!-- WebID HTML snippet. The xmlns declarations above can be moved into the div below if needed-->
+<div about="#me" typeof="foaf:Person">
+ <span property="foaf:name">Bob</span>
+ <h2>My Good Friends</h2>
+ <ul>
+
+ <li rel="foaf:knows" href="https://example.edu/p/Alois#MSc">Alois</li>
+ </ul>
+ <h2>My RSA Public Keys</h2>
+ <div rel="cert:key">
+ <p>I made this key on the 23 November 2011 from my laptop.</p>
+ <div typeof="cert:RSAPublicKey">
+ <dl>
+
+ <dt>Modulus (hexadecimal)</dt>
+ <dd style="word-wrap: break-word; white-space: pre-wrap;"
+ property="cert:modulus" datatype="xsd:hexBinary">cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1</dd>
+ <dt>Exponent (decimal)</dt>
+ <dd property="cert:exponent" datatype="xsd:integer">65537</dd>
+ </dl>
+ </div>
+ </div>
+
+</div>
+<!-- WebID HTML snippet -->
+</body>
+</html></pre>
+<p>The <code>style="word-wrap: break-word; white-space: pre-wrap;"</code> attributes allow the number to be displayed on more than one line so that it will wrapped across lines and not just continue off to the right of the screen.</p>
+<p class="issue">In order to make the above modulus easy to read for humans who may wish to compare it with the modulus in their browser, one can add some javascript. Add some javascript here that adds a : between every two characters, and that splits the line up in chunks.</p>
+<p>If a WebID provider would rather prefer not to mark up his data in RDFa, but
+just provide a human readable format for users and have the RDF graph appear
+in a machine readable format such as RDF/XML then he <em class="rfc2119" title="may">may</em> publish the link from
+the HTML to a machine readable format (it this is available at a dedicated URI)
+as follows:</p>
+ <p class="example">
+</p><pre><html>
+<head>
+<link rel="alternate" type="application/rdf+xml" href="profile.rdf"/>
+</head>
+<body> ... </body>
+</html>
+</pre>
+<p></p>
+</div>
+<div id="in-rdf-xml" typeof="bibo:Chapter" about="#in-rdf-xml" class="section">
+<h4><span class="secno">2.2.3 </span>In RDF/XML</h4>
+<p>RDF/XML is easy to generate automatically from structured data, be it in
+object notation or in relational databases. Parsers for it are also widely
+available.</p>
+
+<pre style="word-wrap: break-word; white-space: pre-wrap;" class="example"><?xml version="1.0"?>
+<rdf:RDF
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
+ xmlns:cert="http://www.w3.org/ns/auth/cert#"
+ xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
+ xmlns:foaf="http://xmlns.com/foaf/0.1/">
+ <foaf:Person rdf:about="https://bob.example/profile#me">
+ <foaf:name>Bob</foaf:name>
+ <foaf:weblog rdf:resource="http://bob.example/blog"/>
+ <cert:key>
+ <cert:RSAPublicKey>
+ <rdfs:label>made on 23 November 2011 on my laptop</rdfs:label>
+ <cert:modulus rdf:datatype="http://www.w3.org/ns/auth/cert#hexBinary">
+cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1
+ </cert:modulus>
+ <cert:exponent rdf:datatype="http://www.w3.org/ns/auth/cert#integer">65537</cert:exponent>
+ </cert:RSAPublicKey>
+ </cert:key>
+ </foaf:Person>
+
+</rdf:RDF></pre>
+<p class="issue">TODO: the dsa ontology</p>
+<p class="todo">What should the time to live be on a WebID document?</p>
+</div>
+<div id="in-portable-contacts-format-using-grddl" typeof="bibo:Chapter" about="#in-portable-contacts-format-using-grddl" class="section">
+<h4><span class="secno">2.2.4 </span>In Portable Contacts format using GRDDL</h4>
+<p class="issue">TODO: discuss other formats and GRDDL, XSPARQL options for xml formats</p>
+<p class="issue">summarize and point to content negotiation documents</p>
+</div>
+</div>
+<div class="normative section" id="disabling-a-webid-certificate" typeof="bibo:Chapter" about="#disabling-a-webid-certificate">
+<h3><span class="secno">2.3 </span>Disabling a WebID Certificate</h3>
+<p>A <a class="tref internalDFN" title="WebID_Certificate" href="#dfn-webid_certificate">WebID Certificate</a> identifies the <a class="tref internalDFN" title="Subject" href="#dfn-subject">Subject</a> alone and no one else, if and only if she is the only one to control the corresponding private key.
+It is very important therefore that the <a class="tref internalDFN" title="Subject" href="#dfn-subject">Subject</a> take care of keeping the <a class="tref" title="private_key">private key</a> secure.
+This can be done by keeping it in the <a class="tref internalDFN" title="Key_Chain" href="#dfn-key_chain">Key Chain</a> 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 <a class="tref" title="private_key">private key</a> has not been lost or copied.
+In the first case the user has to be more careful for signals of misuse.</p><p>
+</p><p>In either situation if the <a class="tref internalDFN" title="Subject" href="#dfn-subject">Subject</a> is suspicious that his private key has been taken, then he can disable future authentications for that certificate by removing the corresponding <a class="tref internalDFN" title="public_key" href="#dfn-public_key">public key</a> from his <a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a>.
+ If the profile contains more than one public key for the <a class="tref internalDFN" title="Subject" href="#dfn-subject">Subject</a> 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>
+</div>
+</div>
+
+<div class="normative section" id="the-webid-protocol" typeof="bibo:Chapter" about="#the-webid-protocol">
+
+<!-- OddPage -->
+<h2><span class="secno">3. </span>The WebID Protocol</h2>
+
+<div class="normative section" id="authentication-sequence" typeof="bibo:Chapter" about="#authentication-sequence">
+<h3><span class="secno">3.1 </span>Authentication Sequence</h3>
+
+<p>In order to give the full context of a <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> interaction with a <a class="tref internalDFN" title="Server" href="#dfn-server">Server</a> we will illustrate the protocol with the following sequence diagram.
+ <a class="tref internalDFN" title="Bob" href="#dfn-bob">Bob</a> initiates a connection to <a class="tref internalDFN" title="Alice" href="#dfn-alice">Alice</a>'s server via a TLS enabled protocol such as HTTPS in order to access a Protected Resource or a Protected Service.
+ The Protected Resource <em class="rfc2119" title="must">must</em> be served over a <a class="tref internalDFN" title="TLS-Light_Service" href="#dfn-tls-light_service">TLS-Light Service</a>, that will not do full <a class="tref internalDFN" title="CA" href="#dfn-ca">CA</a> authentication of <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a>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 <a class="tref internalDFN" title="WebID_Verifier" href="#dfn-webid_verifier">WebID Verifier</a> to verify the non Certified WebIDs found in the certificate.
+ Once the verification succeeds the Guard checks to see if the Agent identified by the <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a> 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" />
+<p>The steps in detail are as follows:</p>
+<ol>
+<li><a class="tref internalDFN" title="Bob" href="#dfn-bob">Bob</a>'s <a class="tref internalDFN" title="Client" href="#dfn-client">Client</a> <em class="rfc2119" title="must">must</em> open a TLS [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC5246">RFC5246</a></cite>] connection with the server which authenticates itself using well known TLS mechanisms. This <em class="rfc2119" title="may">may</em> be done as the first part of an HTTPS connection [<cite><a class="bibref" rel="biblioentry" href="#bib-HTTP-TLS">HTTP-TLS</a></cite>].</li>
+<li>Once the Transport Layer Security [TLS] has been set up, the application protocol exchange can start. If the protocol is HTTP then the client can request an HTTP GET, PUT, POST, DELETE, ... action on a resource as detailed by [<cite><a class="bibref" rel="biblioentry" href="#bib-HTTP11">HTTP11</a></cite>]. The <a class="tref internalDFN" title="Guard" href="#dfn-guard">Guard</a> can then intercept that request and by checking some access control rules determine if the client needs authentication. We will consider the case here where the client does need to be authenticated.</li>
+<li>The Guard <em class="rfc2119" title="must">must</em> requests the client to authenticate itself using public key cryptography by signing a token with its private key and have the Client send its Certificate. This has been carefully defined in the TLS protocol and can be summarised by the following steps:
+<ol>
+<li>The guard requests of the TLS agent that it make a Certificate Request to the client. The TLS layer does this. Because the WebID protocol does not rely on Certificate Authorities to verify the contents of the <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a>, the TLS Agent can ask for any Certificate from the Client. More details in <a href="#requesting-the-client-certificate">Requesting the Client Certificate</a></li>
+<li>The Client asks Bob to choose a certificate if the choice has not been automated. We will assume that Bob does choose a <a class="tref internalDFN" title="WebID_Certificate" href="#dfn-webid_certificate">WebID Certificate</a> and sends it to the client.</li>
+<li>The <a class="tref" title="TLS_Agent">TLS Agent</a> <em class="rfc2119" title="must">must</em> verify that the client is indeed in possession of the private key. What is important here is that the TLS Agent need not know the Issuer of the Certificate, or need not have any trust relation with the Issuer. Indeed if the TLS Layer could verify the signature of the Issuer and trusted the statements it signed, then step 4 and 5 would not be needed - other than perhaps as a way to verify that the key was still valid.</li>
+<li>The <a class="tref internalDFN" title="WebID_Certificate" href="#dfn-webid_certificate">WebID Certificate</a> is then passed on to the <a class="tref internalDFN" title="Guard" href="#dfn-guard">Guard</a> with the proviso that the WebIDs still needs to be verified.</li>
+</ol>
+</li>
+<li>The <a class="tref internalDFN" title="Guard" href="#dfn-guard">Guard</a> then <em class="rfc2119" title="must">must</em> ask the <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> to verify that the WebIDs do identify the agent who knows the given public key.</li>
+<li>The WebID is verified by looking up the definition of the URL at its canonical location. This can be done by dereferencing it. The <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> <em class="rfc2119" title="must">must</em> extract the <a class="tref internalDFN" title="public_key" href="#dfn-public_key">public key</a> and all the URI entries contained in the <code>Subject Alternative Name</code> extension of the <a class="tref internalDFN" title="WebID_Certificate" href="#dfn-webid_certificate">WebID Certificate</a>. A <a class="tref internalDFN" title="WebID_Certificate" href="#dfn-webid_certificate">WebID Certificate</a> <em class="rfc2119" title="may">may</em> contain multiple URI entries
+which are considered claimed <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a>s at this point, since they have not been verified. The <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> may verify as many or as few WebIDs it has time for. It may do it in parallel and asynchronously. However that is done, a claimed WebIDs can only be considered verified if the following steps have been accomplished successfully:</li>
+<ol>
+<li>If the <a class="tref internalDFN" title="WebID_Verifier" href="#dfn-webid_verifier">WebID Verifier</a> does not have an up to date version of the WebID profile in the cache, then it <em class="rfc2119" title="must">must</em> dereference the WebID using the canonical method for dereferencing a URL of that scheme. For an https://... WebID this would be done using the [<cite><a class="bibref" rel="biblioentry" href="#bib-HTTP-TLS">HTTP-TLS</a></cite>] protocol. </li>
+<li>The returned representation is then transformed into an RDF graph as specified in <a href="#processing-the-webid-profile">Processing the WebID Profile</a> </li>
+<li>That graph is then queried as explained in <a href="#querying-the-graph">Querying the Graph</a>. If the query succeeds, then that WebID is verified.
+</li>
+</ol>
+<li>With the set of verified WebIDs the Guard can then check its access control rules using information from the web and other information available to it, to verify if the referent of the WebID is indeed allowed access to the protected resource. The exact nature of those Access Control Rules is left for another specification. Suffice it to say that it can be something as simple as a lookup in a table.</li>
+<li>If access is granted, then the guard can pass on the request to the protected resource, which can then interact unimpeded with the client.</li>
+</ol>
+<ol>
+</ol></div>
+
+<div class="normative section" id="authentication-sequence-details" typeof="bibo:Chapter" about="#authentication-sequence-details">
+<h3><span class="secno">3.2 </span>Authentication Sequence Details</h3>
+
+<p>This section covers details about each step in the authentication process.
+</p>
+
+<div class="normative section" id="initiating-a-tls-connection" typeof="bibo:Chapter" about="#initiating-a-tls-connection">
+<h4><span class="secno">3.2.1 </span>Initiating a TLS Connection</h4>
+
+<p>Standard SSLv3 and TLSv1 and upwards can be used to establish the connection between
+the Client and the TLS Agent 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 <a class="tref" title="TLS_Agent">TLS Agent</a>: they permit the agent to be authenticated in WANT or NEED mode.
+If the client sends a certificate, then neither of these have an impact on the <a class="tref" title="WebID_Verification">WebID Verification</a> 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.
+People don't usually feel comfortable authenticating to a web site on the basis of a certificate alone.
+They prefer human readable text, and detailed error messages which the HTTP layer deliver.
+
+It is better to move the authentication to the application layer <a class="tref internalDFN" title="Guard" href="#dfn-guard">Guard</a> as it has a lot more information about the application state.
+Please see the <a href="http://www.w3.org/2005/Incubator/webid/wiki/">WebID Wiki</a> for implementation pointers in different programming languages and platforms to learn about how this can be done and to share your experience.</p>
+</div>
+
+<div class="normative section" id="connecting-at-the-application-layer" typeof="bibo:Chapter" about="#connecting-at-the-application-layer">
+<h4><span class="secno">3.2.2 </span>Connecting at the Application Layer</h4>
+
+<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><p>If the protocol permits it, the Client can let the Application layer, and especially the <a class="tref internalDFN" title="Guard" href="#dfn-guard">Guard</a> 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>
+<p class="issue">Bergi proposed a header for HTTP which could do this. Please summarise it. </p>
+</div>
+
+
+<div class="normative section" id="requesting-the-client-certificate" typeof="bibo:Chapter" about="#requesting-the-client-certificate">
+<h4><span class="secno">3.2.3 </span>Requesting the Client Certificate</h4>
+
+<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 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC5246">RFC5246</a></cite>]. Since WebID TLS authentication does not rely on CA's signing the certificate to verify the WebID Claims made therein, the Server does not need to restrict the certificate it receives by the CA's 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 [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC5746">RFC5746</a></cite>] 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 far as possible it is important for the server to request the client certificate in <code>WANT</code> mode, not in <code>NEED</code> mode.
+If the request is made in <code>NEED</code> mode then connections will be broken off if the client does not send a certificate.
+This will break the connection at the application protocol layer, and so will lead to a very bad user experience. The server should 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>
+
+</div>
+<div class="normative section" id="verifying-the-webids" typeof="bibo:Chapter" about="#verifying-the-webids">
+<h4><span class="secno">3.2.4 </span>Verifying the WebIDs</h4>
+<p>The <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> is given a list of WebIDs associated with a public key. It needs to verify that the agent identified by that WebID is indeed the agent that controls the private key of the given public key. It does this by looking up the definition of the WebID. A WebID is a URI, and it's meaning can be had by dereferencing it using the protocol indicated in its scheme. </p>
+<p>If we first consider WebIDs with fragment identifiers, we can explain the logic of this as follows. As is explained in the RFC defining URIs [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC3986">RFC3986</a></cite>]
+</p><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 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 in some way.
+If it says that the referent of the WebID is the agent that controls the private key of the given public key, then this is a definite description that can be considered to be a definition of the WebID: it gives its meaning.
+</p>
+<p>The trust that can be had in that statement is therefore the trust that one can have in one's having received the correct representation of the document that defined that WebID.
+An HTTPS WebID will therefore be a lot more trustworthy than an HTTP WebID by a factor of the likelihood of man in the middle attacks.</p>
+<p>Once that is proven then the trust one can have in the agent at the end of the TLS connection being the referent of the WebID is related to the trust one has in the cryptography, and the likelihood that the private key could have been stolen.</p>
+<p class="issue">Add explanation for URI with redirect.</p>
+<div class="normative section" id="processing-the-webid-profile" typeof="bibo:Chapter" about="#processing-the-webid-profile">
+<h5><span class="secno">3.2.4.1 </span>Processing the WebID Profile</h5>
+
+<p>The Verification Agent needs to fetch the document, if it does not have a valid one in cache. The <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> <em class="rfc2119" title="must">must</em> be able to process documents in RDF/XML [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-SYNTAX-GRAMMAR">RDF-SYNTAX-GRAMMAR</a></cite>] and RDFa in XHTML [<cite><a class="bibref" rel="biblioentry" href="#bib-XHTML-RDFA">XHTML-RDFA</a></cite>]. 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 <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> should set the Accept-Header to request <code>application/rdf+xml</code> with a higher priority than <code>text/html</code> and <code>application/xhtml+xml</code>. The reason is that it is quite likely that many sites will produce non marked up HTML and leave the graph to the pure rdf formats.
+</p>
+<p>If the <a class="tref internalDFN" title="Guard" href="#dfn-guard">Guard</a> 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>
+</div>
+
+<div class="normative section" id="verifying-the-webid-claim" typeof="bibo:Chapter" about="#verifying-the-webid-claim">
+<h5><span class="secno">3.2.4.2 </span>Verifying the WebID Claim</h5>
+
+<p>
+To check a WebID claim one has to find if the graph returned by the profile relates the <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a> to the <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a> <a class="tref internalDFN" title="Public_Key" href="#dfn-public_key">Public Key</a> with the <code>cert:key</code> relation. In other words one has to check if those statements are present in the graph.</p>
+
+<div class="normative section" typeof="bibo:Chapter" about="#verifying-the-webid-claim-with-sparql">
+<h6 id="verifying-the-webid-claim-with-sparql">Verifying the WebID Claim with SPARQL</h6>
+<p>Testing for patterns in graphs is what the SPARQL query language is designed to do [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-SPARQL-QUERY">RDF-SPARQL-QUERY</a></cite>]. We will first look at how to use this as it is also the simplest method, and then what some other programmatic options may be.</p>
+<p>Below is the SPARQL Query Template which should be used for an RSA public key. It contains three variables <code>?webid</code>, <code>?mod</code> and <code>?exp</code> that need to be replaced by the appropriate values:</p>
+<pre style="word-wrap: break-word; white-space: pre-wrap;">PREFIX : <http://www.w3.org/ns/auth/cert#>
+PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
+ASK {
+ ?webid :key [
+ :modulus ?mod;
+ :exponent ?exp;
+ ] .
+}
+</pre>
+<p>The variables to be replaced for each WebID claim are:</p>
+<table cellpadding="5" border="1" style="text-align: left; border-color: rgb(0, 0, 0); border-collapse: collapse; word=wrap: break-word; white-psace: pre-wrap">
+<thead>
+ <tr>
+ <th>Variable</th>
+ <th>Details on its value.</th>
+ </tr>
+</thead>
+<tbody>
+<tr><td><code>?webid</code></td><td>should be replaced by the WebID Resource. In the SPARQL notation that is the URL string would be placed between <code><...></code> in the position of the <code>?webid</code> variable. </td></tr>
+<tr><td><code>?mod</code></td><td>should be replaced by the modulus written as a xsd:hexBinary as specified by the <a href="http://www.w3.org/ns/auth/cert#modulus">cert:modulus</a> relation. All leading double 0 bytes (written "00" in hexadecimal) should be removed. The resulting hexadecimal should then be placed in the space of the XXX in <code>"XXX"^^xsd:hexBinary</code> </td></tr>
+<tr><td><code>?exp</code></td><td>should be replaced by the public exponent written as an xsd:integer typed literal. In SPARQL as in Turtle notation this can just be written directly as an integer.</td></tr>
+</tbody>
+</table>
+
+<p>Assuming that we received Bob's key whose modulus starts with <code>cb24ed85d64d794b6...</code> and whose exponent is <code>65537</code> then the following query should be used:
+</p>
+<pre style="word-wrap: break-word; white-space: pre-wrap;" class="example">PREFIX : <http://www.w3.org/ns/auth/cert#>
+PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
+ASK {
+ <https://bob.example/profile#me> :key [
+ :modulus "cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1"^^xsd:hexBinary;
+ :exponent 65537;
+ ] .
+}</pre>
+<p>An ASK query simply returns true or false. If it returns true, then the key was found in the graph with the proper relation and the claim is verified.</p>
+<p>In order to allow the class of queries defined by the template above to return true when asked of graphs where the hexBinary or the exponent contains whitespace characters in initial and final position, the query engine <em class="rfc2119" title="must">must</em> support the D-entailment regime for <code>xsd:hexBinary</code> and <code>xsd:integer</code> as specified in <a href="http://www.w3.org/TR/sparql11-entailment/#DEntRegime">SPARQL 1.1 Entailment Regimes</a>.</p>
+<p>For verifiers that do not have access to a SPARQL query engine but can query the RDF data programmatically, it is relatively easy to emulate the above SPARQL query programmatically. There are a number of ways of doing this, some more efficient than others.</p><p>
+</p></div>
+<div class="normative section" typeof="bibo:Chapter" about="#verifying-the-webid-claim-without-sparql">
+<h6 id="verifying-the-webid-claim-without-sparql">Verifying the WebID claim without SPARQL</h6>
+<p>If the RDF library does datatype normalisation of all literals before loading them, then the most efficient way to execute this would be to start by searching for all triples whose subjects have relation <code>cert:modulus</code> to the literal which in our example was <code>"cb24ed..."^^xsd:hexBinary</code>. One would then iterate through all the subjects of the relations that satisfied that condition, which would most likely never number more than one, and from there filter out all those that were the object of the <code>cert:modulus</code> relation of the <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a> - in the example <code>bob:me</code>. Finally one would verify that one of the keys that had satisfied those relations also had the <code>cert:exponent</code> relation to the number which in the example above is <code>"65537"^^xsd:integer</code>.
+</p>
+<p>For triples stores that do not normalise literals on loading a graph, the normalization will need to be done after the query results and before matching those with the values from the <a class="tref internalDFN" title="Certificate" href="#dfn-certificate">Certificate</a>. Because one could not rely on the modulus having been normalized, one would have to start with the <a class="tref internalDFN" title="WebID" href="#dfn-webid">WebID</a> - <code>bob:me</code> and find all it's <code>cert:key</code> relations to objects - which we know to be keys - and then iterate through each of those keys' modulus and exponent, and verify if the normalised version of the value of those relation is equal to the numbers found in the certificate. If one such key is found then the answer is <code>true</code>, otherwise the answer will be <code>false</code>.</p>
+</div>
+</div>
+<div class="normative section" id="authorization" typeof="bibo:Chapter" about="#authorization">
+<h5><span class="secno">3.2.4.3 </span>Authorization</h5>
+
+<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 <a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a> in order to personalise a site.</p>
+<p>Once the <a class="tref internalDFN" title="Guard" href="#dfn-guard">Guard</a> has a WebID he can do a lookup in a database to see if the agent is allowed the required access to the given resource.
+Up to this point we are not much more advanced that with a user name and password, except that the user did not have to create an account on Alice's server to identify himself and that the server has some claimed attributes to personalise the site for the requestor.
+But the interesting thing about such a WebID is that because it is a global linkable URI, one can build webs of trust that can be crawled the same way the web can be crawled: by following links from one document to another.
+It is therefore possible to have very flexible access control rules where parts of the space of the user's machine is given access to friend and those friends friends (FOAF), stated by them at their domains.
+It is even be possible to allow remote agents to define their own access control rules for parts of the machine's namespace.
+There are too many possibilities to list them all here.
+</p>
+
+</div>
+</div>
+
+<div class="normative section" id="the-webid-profile" typeof="bibo:Chapter" about="#the-webid-profile">
+<h4><span class="secno">3.2.5 </span>The WebID Profile</h4>
+
+<p>The <a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a> is a structured document that contains
+identification credentials for the <a class="tref" title="Identification_Agent">Identification Agent</a> expressed
+using the Resource Description Framework [<cite><a class="bibref" rel="biblioentry" href="#bib-RDF-CONCEPTS">RDF-CONCEPTS</a></cite>]. The following
+sections describe how to express certain common properties that could be used
+by <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a>s and other entities that consume a
+<a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a>.</p>
+
+<div class="normative section" id="personal-information" typeof="bibo:Chapter" about="#personal-information">
+<h5><span class="secno">3.2.5.1 </span>Personal Information</h5>
+
+<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 <em class="rfc2119" title="should">should</em> be used when conveying key pieces of personal information
+but are <em class="rfc2119" title="not required">not required</em> to be present in a <a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a>:</p>
+
+<dl>
+ <dt>foaf:mbox</dt>
+ <dd>The e-mail address that is associated with the WebID URI.</dd>
+ <dt>foaf:name</dt>
+ <dd>The name that is most commonly used to refer to the individual
+ or agent.</dd>
+ <dt>foaf:depiction</dt>
+ <dd>An image representation of the individual or agent.</dd>
+</dl>
+</div>
+
+<div class="normative section" id="cryptographic-details" typeof="bibo:Chapter" about="#cryptographic-details">
+<h5><span class="secno">3.2.5.2 </span>Cryptographic Details</h5>
+
+<p>Cryptographic details are important when <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a>s
+and <a class="tref" title="Identification_Agent">Identification Agent</a>s interact. The following properties
+<em class="rfc2119" title="should">should</em> be used when conveying cryptographic information in
+<a class="tref internalDFN" title="WebID_Profile" href="#dfn-webid_profile">WebID Profile</a> documents:</p>
+
+<dl>
+ <dt>cert:RSAPublicKey</dt>
+ <dd>Expresses an RSA public key. The RSAPublicKey <em class="rfc2119" title="must">must</em> specify the
+ cert:modulus and cert:exponent properties.</dd>
+ <dt>cert:key</dt>
+ <dd>Used to associate a WebID URI with an RSAPublicKey. A WebID Profile
+ <em class="rfc2119" title="must">must</em> contain at least one RSAPublicKey that is associated with the
+ corresponding WebID URI.</dd>
+</dl>
+<p class="note">cert:identity was previously used to associate an RSAPublicKey
+with a WebID URI. cert:identity has been deprecated in favor of its inverse
+property cert:key. Implementors are encouraged to publish WebID Profile
+Documents using cert:key. During this transitional period, implementations
+consuming WebID Profile Documents might still support the deprecated
+cert:identity as well as the stable cert:key.</p>
+</div>
+
+</div>
+
+</div>
+
+</div>
+
+<div id="history" class="appendix informative section" typeof="bibo:Chapter" about="#history">
+
+<!-- OddPage -->
+<h2><span class="secno">A. </span>Change History</h2><p><em>This section is non-normative.</em></p>
+<p><a href="">2011-12-12</a>
+Fixed several errors in examples and diagrams, clarified TLS-Light, added SSL renegotiation, key chain and cache control, updated list people in acknowledgments.
+</p>
+<p><a href="http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-2011-11-23/">2011-11-23</a>
+Wide ranging changes: Rewrote the Verification algorithm now enhanced with a detailed sequence diagram. Moved to new ontology using xsd:hexBinary datatypes and removed rsa: ontology. Rewrote vocabulary section using clearer names. All these changes required serious rewriting everywhere.
+</p>
+<p><a href="https://dvcs.w3.org/hg/WebID/rev/6b60d7335151">2011-02-10</a>
+Move to <a href="http://www.w3.org/2005/Incubator/webid/"><acronym title="World Wide Web Consortium">W3C</acronym> WebID XG</a>.
+Updates from previous unofficial WebID group include changes on
+RDF/XML publishing in HTML, clarification on multiple SAN URIs and
+WebID verification steps.
+</p>
+<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
+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>
+<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>
+<p><a href="https://dvcs.w3.org/hg/WebID/rev/25ba7f596f07">2010-07-11</a>
+Initial version.</p>
+</div>
+
+<div id="acknowledgements" class="informative section" typeof="bibo:Chapter" about="#acknowledgements">
+
+<!-- OddPage -->
+<h2><span class="secno">B. </span>Acknowledgments</h2><p><em>This section is non-normative.</em></p>
+
+<p>The following people have been instrumental in providing thoughts, feedback,
+reviews, criticism and input in the creation of this specification:</p>
+
+<ul>
+<li>Thomas Bergwinkl</li>
+<li>Tim Berners-Lee</li>
+<li>Sarven Capadisli</li>
+<li>Melvin Carvalho</li>
+<li>Martin Gaedke</li>
+<li>Michael Hausenblas</li>
+<li>Kingsley Idehen</li>
+<li>Ian Jacobi</li>
+<li>Nathan Rixham</li>
+<li>Seth Russell</li>
+<li>Andrei Sambra</li>
+<li>Jeff Sayre</li>
+<li>Dominik Tomaszuk</li>
+<li>Peter Williams</li>
+</ul>
+
+</div>
+
+
+
+<div id="references" class="appendix section" typeof="bibo:Chapter" about="#references">
+<!-- OddPage -->
+<h2><span class="secno">C. </span>References</h2><div id="normative-references" typeof="bibo:Chapter" about="#normative-references" class="section"><h3><span class="secno">C.1 </span>Normative references</h3><dl class="bibliography" about=""><dt id="bib-GRDDL-PRIMER">[GRDDL-PRIMER]</dt><dd rel="dcterms:requires">Harry Halpin; Ian Davis. <a href="http://www.w3.org/TR/2007/NOTE-grddl-primer-20070628"><cite>GRDDL Primer.</cite></a> 28 June 2007. W3C Note. URL: <a href="http://www.w3.org/TR/2007/NOTE-grddl-primer-20070628">http://www.w3.org/TR/2007/NOTE-grddl-primer-20070628</a>
+</dd><dt id="bib-HTTP-TLS">[HTTP-TLS]</dt><dd rel="dcterms:requires">E. Rescorla. <a href="http://www.ietf.org/rfc/rfc2818.txt"><cite>HTTP Over TLS.</cite></a> May 2000. Internet RFC 2818. URL: <a href="http://www.ietf.org/rfc/rfc2818.txt">http://www.ietf.org/rfc/rfc2818.txt</a>
+</dd><dt id="bib-HTTP11">[HTTP11]</dt><dd rel="dcterms:requires">R. Fielding; et al. <a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext Transfer Protocol - HTTP/1.1.</cite></a> June 1999. Internet RFC 2616. URL: <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>
+</dd><dt id="bib-N3">[N3]</dt><dd rel="dcterms:requires">Tim Berners-Lee; Dan Connolly. <a href="http://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/"><cite>Notation3 (N3): A readable RDF syntax.</cite></a> 14 January 2008. W3C Team Submission. URL: <a href="http://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/">http://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/</a>
+</dd><dt id="bib-RDF-PRIMER">[RDF-PRIMER]</dt><dd rel="dcterms:requires">Frank Manola; Eric Miller. <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/"><cite>RDF Primer.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">http://www.w3.org/TR/2004/REC-rdf-primer-20040210/</a>
+</dd><dt id="bib-RDF-SPARQL-QUERY">[RDF-SPARQL-QUERY]</dt><dd rel="dcterms:requires">Andy Seaborne; Eric Prud'hommeaux. <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115"><cite>SPARQL Query Language for RDF.</cite></a> 15 January 2008. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115">http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115</a>
+</dd><dt id="bib-RDF-SYNTAX-GRAMMAR">[RDF-SYNTAX-GRAMMAR]</dt><dd rel="dcterms:requires">Dave Beckett. <a href="http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210"><cite>RDF/XML Syntax Specification (Revised).</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210">http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210</a>
+</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd rel="dcterms:requires">T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax.</cite></a> January 2005. Internet RFC 3986. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
+</dd><dt id="bib-RFC5246">[RFC5246]</dt><dd rel="dcterms:requires">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>
+</dd><dt id="bib-RFC5746">[RFC5746]</dt><dd rel="dcterms:requires">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>
+</dd><dt id="bib-TURTLE">[TURTLE]</dt><dd rel="dcterms:requires">David Beckett, Tim Berners-Lee. <a href="http://www.w3.org/TeamSubmission/turtle/"><cite>Turtle: Terse RDF Triple Language.</cite></a> January 2008. W3C Team Submission. URL: <a href="http://www.w3.org/TeamSubmission/turtle/">http://www.w3.org/TeamSubmission/turtle/</a>
+</dd><dt id="bib-X509V3">[X509V3]</dt><dd rel="dcterms:requires"><cite>ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open Systems Interconnection - The Directory Authentication Framework" ISO/IEC 9594-8:1997</cite>.
+</dd><dt id="bib-XHTML-RDFA">[XHTML-RDFA]</dt><dd rel="dcterms:requires">Shane McCarron; et. al. <a href="http://www.w3.org/TR/2011/WD-xhtml-rdfa-20111215"><cite>XHTML+RDFa 1.1.</cite></a> 15 December 2011. W3C Working Draft. URL: <a href="http://www.w3.org/TR/2011/WD-xhtml-rdfa-20111215">http://www.w3.org/TR/2011/WD-xhtml-rdfa-20111215</a>
+</dd></dl></div><div id="informative-references" typeof="bibo:Chapter" about="#informative-references" class="section"><h3><span class="secno">C.2 </span>Informative references</h3><dl class="bibliography" about=""><dt id="bib-RDF-CONCEPTS">[RDF-CONCEPTS]</dt><dd rel="dcterms:references">Graham Klyne; Jeremy J. Carroll. <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210"><cite>Resource Description Framework (RDF): Concepts and Abstract Syntax.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210">http://www.w3.org/TR/2004/REC-rdf-concepts-20040210</a>
+</dd></dl></div></div></body></html>