Added ReSpec source of WebID specification and first editors draft.
authorManu Sporny <msporny@digitalbazaar.com>
Sun, 11 Jul 2010 16:40:42 -0400
changeset 225ba7f596f07
child 3 2919284fab9e
Added ReSpec source of WebID specification and first editors draft.
drafts/ED-webid-20100711/index.html
index-respec.html
index.html
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/drafts/ED-webid-20100711/index.html	Sun Jul 11 16:40:42 2010 -0400
     1.3 @@ -0,0 +1,460 @@
     1.4 +<?xml version='1.0' encoding='UTF-8'?>
     1.5 +<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML+RDFa 1.0//EN' 'http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd'>
     1.6 +<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#'>
     1.7 +<head>
     1.8 +    <title>WebID 1.0</title>
     1.9 +    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    1.10 +    
    1.11 +<!--  
    1.12 +      === NOTA BENE ===
    1.13 +      For the three scripts below, if your spec resides on dev.w3 you can check them
    1.14 +      out in the same tree and use relative links so that they'll work offline,
    1.15 +      -->
    1.16 +
    1.17 +<style type="text/css">
    1.18 +code           { font-family: monospace; }
    1.19 +
    1.20 +span.hilite { color: red; /* font-weight: bold */ }
    1.21 +
    1.22 +li p           { margin-top: 0.3em;
    1.23 +                 margin-bottom: 0.3em; }
    1.24 +
    1.25 +div.explanation { background-color: #ADD8E6;
    1.26 +                   width: 80%;
    1.27 +                   margin: 12px; padding: 8px; }
    1.28 +div.explanation li { margin-top: 8px; }
    1.29 +div.explanation dd { margin: 4px; }
    1.30 +
    1.31 +.adef { 
    1.32 +	font-family: monospace; 
    1.33 +	font-weight: bold; 
    1.34 +    color: #ff4500 !important;
    1.35 +}
    1.36 +
    1.37 +.aref { 
    1.38 +	font-family: monospace; 
    1.39 +	font-weight: bold; 
    1.40 +    color: #ff4500 !important;
    1.41 +}
    1.42 +
    1.43 +span.entity { color: red; }
    1.44 +
    1.45 +span.element { color: green; }
    1.46 +</style>
    1.47 +
    1.48 +     
    1.49 +
    1.50 +<!--     <script src='/ReSpec.js/js/respec.js' class='remove'></script>  -->
    1.51 +
    1.52 +    
    1.53 +  <link href="http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css" rel="stylesheet" type="text/css" charset="utf-8" /><link href="http://www.w3.org/StyleSheets/TR/w3c-unofficial" rel="stylesheet" type="text/css" charset="utf-8" /></head><body style="display: inherit; "><div class="head"><p></p><h1 rel="dcterms:title" class="title" id="title">WebID 1.0</h1><h2 rel="bibo:subtitle" id="subtitle">Web Identification and Discovery</h2><h2 property="dcterms:issued" datatype="xsd:dateTime" content="2010-07-11T20:21:06+0000" id="unofficial-draft-11-july-2010">Unofficial Draft 11 July 2010</h2><dl><dt>Editor:</dt><dd rel="bibo:editor"><span typeof="foaf:Person"><span property="foaf:name">Manu Sporny</span>, <a rel="foaf:workplaceHomepage" href="http://blog.digitalbazaar.com/">Digital Bazaar, Inc.</a> <a rel="foaf:mbox" href="mailto:msporny@digitalbazaar.com">msporny@digitalbazaar.com</a> </span>
    1.54 +</dd>
    1.55 +<dt>Authors:</dt><dd><span><span>Toby Inkster</span></span>
    1.56 +</dd>
    1.57 +<dd><span><a content="Henry Story" href="http://bblfish.net/">Henry Story</a></span>
    1.58 +</dd>
    1.59 +</dl><p class="copyright">This document is licensed under a <a class="subfoot" href="http://creativecommons.org/licenses/by/3.0/" rel="license">Creative Commons Attribution 3.0 License</a>.</p><hr></hr></div>
    1.60 +    <div id="abstract" class="introductory section" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" about="#abstract"><h2>Abstract</h2>
    1.61 +
    1.62 +<p>Privacy and Identification on the Web have been at the center of how we
    1.63 +interact with sites on the Web. The explosion of Websites over the last decade
    1.64 +and a half has created a point of pain for anyone that uses the Web on a
    1.65 +regular basis. Remembering login details, passwords,
    1.66 +and sharing private information across the many websites that people use on a
    1.67 +daily basis has become more difficult and complicated than necessary. This 
    1.68 +specification outlines a simple universal identification mechanism that is
    1.69 +distributed, openly extensible, improves privacy, security and control over how 
    1.70 +one can identify themselves on the Web.</p>
    1.71 +  
    1.72 +<div typeof="bibo:Chapter" about="#how-to-read-this-document" class="section">
    1.73 +<h3 id="how-to-read-this-document">How to Read this Document</h3>
    1.74 +  
    1.75 +<p>There are a number of concepts that are covered in this document that the
    1.76 +reader may want to be aware of before continuing. General knowledge of
    1.77 +<a href="http://en.wikipedia.org/wiki/Public_key_cryptography">public key cryptography</a> 
    1.78 +is necessary to understand how to implement this specification. 
    1.79 +WebID also uses HTTP over TLS [<a class="bibref" rel="biblioentry" href="#bib-HTTP-TLS">HTTP-TLS</a>], X.509 certificates
    1.80 +[<a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a>], and RDFa [<a class="bibref" rel="biblioentry" href="#bib-RDFA-CORE">RDFA-CORE</a>].</p>
    1.81 +
    1.82 +<p>A general <a href="#introduction">Introduction</a> is provided for all that
    1.83 +would like to understand why this specification is necessary to simplify usage
    1.84 +of the Web.</p>
    1.85 +
    1.86 +<p>The terms used throughout this specification are listed in the section
    1.87 +titled <a href="#terminology">Terminology</a>.</p>
    1.88 +
    1.89 +<p>Developers that are interested in implementing this specification will be
    1.90 +most interested in the sections titled 
    1.91 +<a href="#authentication-sequence">Authentication Sequence</a> and 
    1.92 +<a href="#authentication-sequence-details">Authentication Sequence Details</a>.
    1.93 +  
    1.94 +</p></div>
    1.95 +</div><div id="sotd" class="introductory section" typeof="bibo:Chapter" about="#sotd"><h2>Status of This Document</h2><p>This document is merely a public working draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.</p>
    1.96 +
    1.97 +<!--  <p>This document has been reviewed by W3C Members, by software
    1.98 +developers, and by other W3C groups and interested parties, and is
    1.99 +endorsed by the Director as a W3C Recommendation. It is a stable
   1.100 +document and may be used as reference material or cited from another
   1.101 +document. W3C's role in making the Recommendation is to draw attention
   1.102 +to the specification and to promote its widespread deployment. This
   1.103 +enhances the functionality and interoperability of the Web.</p>  -->
   1.104 +
   1.105 +
   1.106 +</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="#motivation" class="tocxref"><span class="secno">1.1 </span>Motivation</a></li><li class="tocline"><a href="#relation-to-openid" class="tocxref"><span class="secno">1.2 </span>Relation to OpenID</a></li><li class="tocline"><a href="#relation-to-oauth" class="tocxref"><span class="secno">1.3 </span>Relation to OAuth</a></li></ul></li><li class="tocline"><a href="#the-webid-protocol" class="tocxref"><span class="secno">2. </span>The WebID Protocol</a><ul class="toc"><li class="tocline"><a href="#terminology" class="tocxref"><span class="secno">2.1 </span>Terminology</a></li><li class="tocline"><a href="#authentication-sequence" class="tocxref"><span class="secno">2.2 </span>Authentication Sequence</a></li><li class="tocline"><a href="#authentication-sequence-details" class="tocxref"><span class="secno">2.3 </span>Authentication Sequence Details</a><ul class="toc"><li class="tocline"><a href="#initiating-a-tls-connection" class="tocxref"><span class="secno">2.3.1 </span>Initiating a TLS Connection</a></li><li class="tocline"><a href="#exchanging-the-identification-certificate" class="tocxref"><span class="secno">2.3.2 </span>Exchanging the Identification Certificate</a></li><li class="tocline"><a href="#processing-the-webid-url" class="tocxref"><span class="secno">2.3.3 </span>Processing the WebID URL</a></li><li class="tocline"><a href="#extracting-identification-url-details" class="tocxref"><span class="secno">2.3.4 </span>Extracting Identification URL Details</a></li><li class="tocline"><a href="#determining-access-privileges" class="tocxref"><span class="secno">2.3.5 </span>Determining Access Privileges</a></li></ul></li></ul></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">A. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">A.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">A.2 </span>Informative references</a></li></ul></li></ul></div>
   1.107 +
   1.108 +
   1.109 +
   1.110 +<div class="informative section" id="introduction" typeof="bibo:Chapter" about="#introduction">
   1.111 +
   1.112 +<!-- OddPage -->
   1.113 +<h2><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
   1.114 +
   1.115 +<p>
   1.116 +The WebID specification is designed to help alleviate the difficultly that
   1.117 +remembering different logins, passwords and settings for websites has created. 
   1.118 +It is also designed to provide a universal and extensible mechanism to express 
   1.119 +public and private information about yourself. This section outlines the 
   1.120 +motivation behind the specification and the relationship to other similar 
   1.121 +specifications that are in active use today.
   1.122 +</p>
   1.123 +
   1.124 +<div class="informative section" id="motivation" typeof="bibo:Chapter" about="#motivation">
   1.125 +<h3><span class="secno">1.1 </span>Motivation</h3><p><em>This section is non-normative.</em></p>
   1.126 +
   1.127 +<p>
   1.128 +It is a fundamental design criteria of the Web to enable individuals and
   1.129 +organizations to control how they interact with the rest of society. This
   1.130 +includes how one expresses their identity, public information and personal 
   1.131 +details to social networks, Web sites and services.
   1.132 +</p>
   1.133 +
   1.134 +<p>
   1.135 +Semantic Web vocabularies such as Friend-of-a-Friend (FOAF) permit distributed 
   1.136 +hyperlinked social networks to exist. This vocabulary, along with other 
   1.137 +vocabularies, allow one to add information and services protection to 
   1.138 +distributed social networks.
   1.139 +</p>
   1.140 +
   1.141 +<p>
   1.142 +One major criticism of open networks is that they seem to have no way of
   1.143 +protecting the personal information distributed on the web or limiting
   1.144 +access to resources. Few people are willing to make all their personal
   1.145 +information public, many would like large pieces to be protected, making
   1.146 +it available only to a select group of agents. Giving access to
   1.147 +information is very similar to giving access to services. There are many
   1.148 +occasions when people would like services to only be accessible to
   1.149 +members of a group, such as allowing only friends, family members,
   1.150 +colleagues to post an article, photo or comment on a blog. How does one do
   1.151 +this in a flexible way, without requiring a central point of
   1.152 +access control?
   1.153 +</p>
   1.154 +
   1.155 +<p>
   1.156 +Using an process made popular by OpenID, we show how one can tie a User
   1.157 +Agent to a URL by proving that one has write access to the URL. WebID is
   1.158 +a simpler alternative to OpenID (fewer connections), that uses X.509 
   1.159 +certificates to tie a User Agent (Browser) to a Person identified via a URL. 
   1.160 +WebID also provides a few additional features to OpenID. These
   1.161 +features include trust management, via digital signatures, and free-form 
   1.162 +extensibility via RDFa. By using the existing SSL certificate exchange
   1.163 +mechanism, WebID integrates more smoothly with existing Web browsers, including
   1.164 +browsers on mobile devices. WebID also permits automated session login
   1.165 +in addition to interactive session login. Additionally, all data is encrypted
   1.166 +and guaranteed to only be received by the person or organization that was 
   1.167 +intended to receive it.
   1.168 +</p>
   1.169 +
   1.170 +</div>
   1.171 +
   1.172 +<div class="informative section" id="relation-to-openid" typeof="bibo:Chapter" about="#relation-to-openid">
   1.173 +<h3><span class="secno">1.2 </span>Relation to OpenID</h3><p><em>This section is non-normative.</em></p>
   1.174 +
   1.175 +<p>While some may say that OpenID and WebID conflict, WebID is 100% compatible
   1.176 +with OpenID since both use a URL for identification. Therefore, WebID does not
   1.177 +intend to replace OpenID, but can work beside OpenID just as easily as providing
   1.178 +a complete solution. That said, there are a number of benefits that WebID
   1.179 +achieves over OpenID:
   1.180 +</p>
   1.181 +
   1.182 +<p>WebID gives people and other agents a Web ID URL for identification, just
   1.183 +like OpenId does. However, in the case of WebID, the user does not need to
   1.184 +remember the URL, the browser or User Agent does. A login button on a
   1.185 +WebID web site is just a button. No need to enter any identifier like one
   1.186 +has to for OpenID. Just click the button. Your browser will then ask you what 
   1.187 +identity you wish to use. The person that is browsing does not need to 
   1.188 +remember either the WebID URL or the website password. The only password one
   1.189 +needs to remember is the one that is used to access their collection of
   1.190 +WebIDs in their browser.</p>
   1.191 +
   1.192 +<p>The WebID protocol requires just one direct network connection to establish
   1.193 +identity via the client. The server requires one connection to the client and
   1.194 +one connection to retrieve the WebID URL if it does not have the credential
   1.195 +information cached. Compare this to the much more complex OpenID sequence, which
   1.196 +requires six connections by the client to establish a login. In a world of 
   1.197 +distributed data where each site can point to data on any other site, multiple 
   1.198 +connections become costly to manage.</p>
   1.199 +
   1.200 +<p>WebID builds on well established Internet and Web standards;
   1.201 +<a href="http://en.wikipedia.org/wiki/REST">REST</a>, 
   1.202 +RDF [<a class="bibref" rel="biblioentry" href="#bib-RDF-PRIMER">RDF-PRIMER</a>], RDFa [<a class="bibref" rel="biblioentry" href="#bib-RDFA-CORE">RDFA-CORE</a>], TLS [<a class="bibref" rel="biblioentry" href="#bib-HTTP-TLS">HTTP-TLS</a>], and X.509 
   1.203 +[<a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a>]. By building on previous standards, it makes both explaining and 
   1.204 +implementing WebID easier on developers.</p>
   1.205 +
   1.206 +<p>Since WebID is RESTful, you can perform basic HTTP operations to 
   1.207 +<code>GET</code> your WebID, and if you needed update it, you can use
   1.208 +HTTP <code>PUT</code> semantics. You can also create a WebID via 
   1.209 +<code>POST</code>. This is improved from the OpenID specification, which
   1.210 +requires a new set of operations described in the OpenID Attribute Exchange
   1.211 +specification.</p>
   1.212 +
   1.213 +<p>It is easy to extend a WebID with new attributes via RDF. The power of
   1.214 +RDF and RDFa allows developers to add extensions to WebID by defining new
   1.215 +vocabularies that they publish. There is no authorization process necessary
   1.216 +and thus WebID allows for distributed innovation. Every WebID property is
   1.217 +a URI, which when clicked, can give you yet more information about what the
   1.218 +property means. A developer can create new usage classes by extending their
   1.219 +vocabulary at will. A developer can add relationships to a WebID by simply
   1.220 +adding more HTML to the developer's page. OpenID does not provide any type of
   1.221 +distributed innovation akin to RDF or RDFa.</p>
   1.222 +
   1.223 +<p>WebID is built on RDF and thus enables all of the advanced semantic web
   1.224 +concepts that RDF enables. For example, a developer may perform machine
   1.225 +reasoning with a WebID. One can construct machine-executable statements like
   1.226 +"If this WebID claims to be a friend of one of our partner WebIDs that is
   1.227 +trusted and the relationship is bi-directional, trust the WebID." 
   1.228 +While OpenID attempts to support this use case by mapping OpenID to RDF, it's
   1.229 +far easier to do with WebID because WebID is natively RDF-aware.</p>
   1.230 +
   1.231 +<p>Implementing WebID is easier than OpenID because all of the basic 
   1.232 +technologies have been working and integrated into Web browsers for many years. 
   1.233 +There were already three interoperable implementations of WebID before this 
   1.234 +specification was written.</p>
   1.235 +
   1.236 +<p>WebID is truly decentralized - with WebID you get a web of trust. 
   1.237 +OpenID only supports the Web of Trust model if you indirectly trust the
   1.238 +OpenID provider. In other words - OpenID is not truly decentralized. In OpenID
   1.239 +you must trust OpenID providers. With WebID you only have to trust the people
   1.240 +and the organizations with which you are communicating. In other words, you
   1.241 +don't have to ask anyone whether or not you can trust your friends. You can
   1.242 +query people that you trust directly to see if someone is trustworthy or not.
   1.243 +There is no need for a central WebID authority.
   1.244 +</p>
   1.245 +
   1.246 +<p>WebID is fully distributed, anyone can setup a WebID by placing a single
   1.247 +file on a web server of their choosing. There is no need for a special 
   1.248 +OpenID-like provider service. The only thing anyone that wants a WebID needs
   1.249 +is a web account where you can post your WebID file, ideally on your own domain 
   1.250 +name. You can also use a WebID hosting provider, but it's not necessary for
   1.251 +WebID to work. While it is possible to run an OpenID server, other
   1.252 +OpenID applications may not trust you and thus you won't be able to fully
   1.253 +utilize your private OpenID credentials. The reason that there are a few
   1.254 +large OpenID providers and very few small OpenID providers is because of this
   1.255 +trust design issue related to OpenID.</p>
   1.256 +
   1.257 +<p>WebID does not require HTTP redirects. Redirects are are problematic on many
   1.258 +cell phones, because telecoms heavily rely on proxys, which selectively block
   1.259 +redirects.</p>
   1.260 +
   1.261 +<p>A WebID provider is 100% compatible with an OpenID provider and thus can 
   1.262 +inter-operate with OpenID-powered networks.</p>
   1.263 +
   1.264 +</div>
   1.265 +
   1.266 +<div class="informative section" id="relation-to-oauth" typeof="bibo:Chapter" about="#relation-to-oauth">
   1.267 +<h3><span class="secno">1.3 </span>Relation to OAuth</h3><p><em>This section is non-normative.</em></p>
   1.268 +
   1.269 +<p>
   1.270 +OAuth and WebID are mutually beneficial when used together. WebID can be
   1.271 +used to provide RSA parameters to the RSA-SHA1 signature method required by
   1.272 +OAuth 1.0. WebID can also be used to establish the consumer_key and HTTPS 
   1.273 +connection that will be used to transmit OAuth Tokens in OAuth 2.0.
   1.274 +</p>
   1.275 +
   1.276 +</div>
   1.277 +</div>
   1.278 +
   1.279 +<div class="normative section" id="the-webid-protocol" typeof="bibo:Chapter" about="#the-webid-protocol">
   1.280 +
   1.281 +<!-- OddPage -->
   1.282 +<h2><span class="secno">2. </span>The WebID Protocol</h2>
   1.283 +
   1.284 +<div class="normative section" id="terminology" typeof="bibo:Chapter" about="#terminology">
   1.285 +<h3><span class="secno">2.1 </span>Terminology</h3>
   1.286 +
   1.287 +<dl>
   1.288 +<dt><dfn title="Verification_Agent" id="dfn-verification_agent">Verification Agent</dfn></dt>
   1.289 +<dd>Performs authentication on provided WebID credentials and determines if
   1.290 +an <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a> can have access to a particular 
   1.291 +resource. A <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> is typically a Web server, but 
   1.292 +may also be a peer on a peer-to-peer network.</dd>
   1.293 +<dt><dfn title="Identification_Agent" id="dfn-identification_agent">Identification Agent</dfn></dt>
   1.294 +<dd>Provides identification credentials to a Verification Agent. The
   1.295 +<a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a> is typically also a User Agent.</dd>
   1.296 +<dt><dfn title="Identification_Certificate" id="dfn-identification_certificate">Identification Certificate</dfn></dt>
   1.297 +<dd>An X.509 [<a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a>] Certificate that <em class="rfc2119" title="must">must</em> contain the 
   1.298 +<code>Subject Alternative Name</code> field pointing to a URL that is
   1.299 +dereference-able and results in an [<a class="bibref" rel="biblioentry" href="#bib-XHTML-RDFA">XHTML-RDFA</a>] document. For example 
   1.300 +the certificate would contain <code>http://example.org/webid#public</code> as
   1.301 +the <code>Subject Alternative Name</code>:
   1.302 +<code><pre>
   1.303 +X509v3 extensions:
   1.304 +   ...
   1.305 +   X509v3 Subject Alternative Name:
   1.306 +      URI:http://example.org/webid#public
   1.307 +</pre></code>
   1.308 +</dd><dt><dfn title="WebID_URL" id="dfn-webid_url">WebID URL</dfn></dt>
   1.309 +<dd>The URL that contains identification credentials for the 
   1.310 +<a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a> encoded in RDFa [<a class="bibref" rel="biblioentry" href="#bib-XHTML-RDFA">XHTML-RDFA</a>].</dd>
   1.311 +
   1.312 +</dl>
   1.313 +
   1.314 +</div>
   1.315 +
   1.316 +<div class="normative section" id="authentication-sequence" typeof="bibo:Chapter" about="#authentication-sequence">
   1.317 +<h3><span class="secno">2.2 </span>Authentication Sequence</h3>
   1.318 +
   1.319 +<p>The following steps are executed by Verification Agents and Identification
   1.320 +Agents to determine if access should be granted to a particular resource.
   1.321 +</p>
   1.322 +
   1.323 +<ol>
   1.324 +<li>The <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a> attempts to access a resource
   1.325 +using HTTP over TLS [<a class="bibref" rel="biblioentry" href="#bib-HTTP-TLS">HTTP-TLS</a>] via the <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a>.</li>
   1.326 +
   1.327 +<li>The <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> <em class="rfc2119" title="must">must</em> request the 
   1.328 +<a class="tref internalDFN" title="Identification_Certificate" href="#dfn-identification_certificate">Identification Certificate</a> of the <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a>
   1.329 +as a part of the TLS client-cerificate retrieval protocol.</li>
   1.330 +
   1.331 +<li>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="WebID_URL" href="#dfn-webid_url">WebID URL</a> 
   1.332 +contained in the <code>Subject Alternative Name</code> field of the 
   1.333 +<a class="tref internalDFN" title="Identification_Certificate" href="#dfn-identification_certificate">Identification Certificate</a>. The <a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a> <em class="rfc2119" title="must">must</em> be 
   1.334 +dereferenced and the resulting document processed according to [<a class="bibref" rel="biblioentry" href="#bib-XHTML-RDFA">XHTML-RDFA</a>]. 
   1.335 +All triples pertaining to the public key associated with the 
   1.336 +<a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a> <em class="rfc2119" title="must">must</em> be extracted from the remote document.</li>
   1.337 +
   1.338 +<li>The remote document triples <em class="rfc2119" title="must">must</em> be queried for information about the 
   1.339 +public key contained in the <a class="tref internalDFN" title="Identification_Certificate" href="#dfn-identification_certificate">Identification Certificate</a>. 
   1.340 +If the public key in the certificate is found in the list of public keys 
   1.341 +associated with the <a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a>, the <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a>
   1.342 +<em class="rfc2119" title="must">must</em> assume that the client has write access to the <a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a> and
   1.343 +therefore owns the URL.</li>
   1.344 +
   1.345 +<li>At this point, the <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> has verified that the
   1.346 +<a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a> is owned by the <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a>. The
   1.347 +<a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> <em class="rfc2119" title="must">must</em> use the now verified public key contained 
   1.348 +in the <a class="tref internalDFN" title="Identification_Certificate" href="#dfn-identification_certificate">Identification Certificate</a> for all TLS-based communication
   1.349 +with the <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a>.
   1.350 +</li></ol>
   1.351 +
   1.352 +<p>
   1.353 +The <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a> <em class="rfc2119" title="may">may</em> re-establish a different identity at 
   1.354 +any time by executing all of the steps in the Authentication Sequence again. 
   1.355 +Additional algorithms, detailed in the next section, <em class="rfc2119" title="may">may</em> be performed to 
   1.356 +determine if the <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> can access a particular 
   1.357 +resource after the last step of the Authentication Sequence has been
   1.358 +completed.
   1.359 +</p>
   1.360 +
   1.361 +</div>
   1.362 +
   1.363 +<div class="normative section" id="authentication-sequence-details" typeof="bibo:Chapter" about="#authentication-sequence-details">
   1.364 +<h3><span class="secno">2.3 </span>Authentication Sequence Details</h3>
   1.365 +
   1.366 +<p>This section covers details about each step in the authentication process.
   1.367 +</p>
   1.368 +
   1.369 +<div class="normative section" id="initiating-a-tls-connection" typeof="bibo:Chapter" about="#initiating-a-tls-connection">
   1.370 +<h4><span class="secno">2.3.1 </span>Initiating a TLS Connection</h4>
   1.371 +
   1.372 +<p class="issue">This section will detail how the TLS connection process is
   1.373 +started and used by WebID to create a secure channel between the 
   1.374 +Identification Agent and the Verification Agent.</p>
   1.375 +</div>
   1.376 +
   1.377 +<div class="normative section" id="exchanging-the-identification-certificate" typeof="bibo:Chapter" about="#exchanging-the-identification-certificate">
   1.378 +<h4><span class="secno">2.3.2 </span>Exchanging the Identification Certificate</h4>
   1.379 +
   1.380 +<p class="issue">This section will detail how the certificate is selected and
   1.381 +sent to the Verification Agent.</p>
   1.382 +</div>
   1.383 +
   1.384 +<div class="normative section" id="processing-the-webid-url" typeof="bibo:Chapter" about="#processing-the-webid-url">
   1.385 +<h4><span class="secno">2.3.3 </span>Processing the WebID URL</h4>
   1.386 +
   1.387 +<p class="issue">This section will explain how a Verification Agent extracts 
   1.388 +semantic data describing the identification credentials from a WebID URL.</p>
   1.389 +</div>
   1.390 +
   1.391 +<div class="normative section" id="extracting-identification-url-details" typeof="bibo:Chapter" about="#extracting-identification-url-details">
   1.392 +<h4><span class="secno">2.3.4 </span>Extracting Identification URL Details</h4>
   1.393 +
   1.394 +<p>
   1.395 +The <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> may use a number of different methods to
   1.396 +extract the public key information from the <a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a>.
   1.397 +</p>
   1.398 +The following SPARQL query outlines one way in which the public key
   1.399 +could be extracted from the <a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a>:
   1.400 +<code><pre>
   1.401 +PREFIX cert: &lt;http://www.w3.org/ns/auth/cert#&gt;
   1.402 +PREFIX rsa: &lt;http://www.w3.org/ns/auth/rsa#&gt;
   1.403 +SELECT ?modulus ?exp
   1.404 +WHERE {
   1.405 +   ?key cert:identity &lt;http://example.org/webid#public&gt;;
   1.406 +      a rsa:RSAPublicKey;
   1.407 +      rsa:modulus [ cert:hex ?modulus; ];
   1.408 +      rsa:public_exponent [ cert:decimal ?exp ] .
   1.409 +}
   1.410 +</pre></code>
   1.411 +
   1.412 +<p class="issue">This section still needs more information.</p>
   1.413 +
   1.414 +</div>
   1.415 +
   1.416 +<div class="normative section" id="determining-access-privileges" typeof="bibo:Chapter" about="#determining-access-privileges">
   1.417 +<h4><span class="secno">2.3.5 </span>Determining Access Privileges</h4>
   1.418 +
   1.419 +<p class="issue">This section will explain how a Verification Agent may
   1.420 +use the information discovered via a WebID URL to determine if one should
   1.421 +be able to access a particular resource. It will explain how a Verification
   1.422 +Agent can use links to other RDFa documents to build knowledge about the
   1.423 +given WebID.</p>
   1.424 +
   1.425 +</div>
   1.426 +
   1.427 +</div>
   1.428 +
   1.429 +<div id="appendix" typeof="bibo:Chapter" about="#appendix" class="section">
   1.430 +
   1.431 +<div class="informative section" id="history" typeof="bibo:Chapter" about="#history">
   1.432 +<h4>Change History</h4><p><em>This section is non-normative.</em></p>
   1.433 +<p>2010-07-11 Initial version.</p>
   1.434 +</div>
   1.435 +
   1.436 +<div class="informative section" id="acknowledgements" typeof="bibo:Chapter" about="#acknowledgements">
   1.437 +<h4>Acknowledgments</h4><p><em>This section is non-normative.</em></p>
   1.438 +
   1.439 +<p>The following people have been instrumental in providing thoughts, feedback,
   1.440 +reviews, criticism and input in the creation of this specification:</p>
   1.441 +
   1.442 +<ul>
   1.443 +<li>Melvin Carvalho</li>
   1.444 +<li>Bruno Harbulot</li>
   1.445 +<li>Toby Inkster</li>
   1.446 +<li>Ian Jacobi</li>
   1.447 +<li>Jeff Sayre</li>
   1.448 +<li>Henry Story</li>
   1.449 +</ul>
   1.450 +
   1.451 +</div>
   1.452 +</div>
   1.453 +  
   1.454 +
   1.455 +
   1.456 +</div><div id="references" class="appendix section" typeof="bibo:Chapter" about="#references">
   1.457 +<!-- OddPage -->
   1.458 +<h2><span class="secno">A. </span>References</h2><div id="normative-references" typeof="bibo:Chapter" about="#normative-references" class="section"><h3><span class="secno">A.1 </span>Normative references</h3><dl class="bibliography" about=""><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> 
   1.459 +</dd><dt id="bib-RDFA-CORE">[RDFA-CORE]</dt><dd rel="dcterms:requires">Shane McCarron; et al. <a href="http://www.w3.org/TR/2010/WD-rdfa-core-20100422"><cite>RDFa Core 1.1: Syntax and processing rules for embedding RDF through attributes.</cite></a>22 April 2010. W3C Working Draft. URL: <a href="http://www.w3.org/TR/2010/WD-rdfa-core-20100422">http://www.w3.org/TR/2010/WD-rdfa-core-20100422</a> 
   1.460 +</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>.
   1.461 +</dd><dt id="bib-XHTML-RDFA">[XHTML-RDFA]</dt><dd rel="dcterms:requires">Shane McCarron; et. al. <a href="http://www.w3.org/TR/2010/WD-xhtml-rdfa-20100422"><cite>XHTML+RDFa 1.1.</cite></a> 22 April 2010. W3C Working Draft. URL: <a href="http://www.w3.org/TR/2010/WD-xhtml-rdfa-20100422">http://www.w3.org/TR/WD-xhtml-rdfa-20100422</a> 
   1.462 +</dd></dl></div><div id="informative-references" typeof="bibo:Chapter" about="#informative-references" class="section"><h3><span class="secno">A.2 </span>Informative references</h3><dl class="bibliography" about=""><dt id="bib-RDF-PRIMER">[RDF-PRIMER]</dt><dd rel="dcterms:references">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> 
   1.463 +</dd></dl></div></div></body></html>
     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/index-respec.html	Sun Jul 11 16:40:42 2010 -0400
     2.3 @@ -0,0 +1,659 @@
     2.4 +<?xml version='1.0' encoding='UTF-8'?>
     2.5 +<!DOCTYPE html>
     2.6 +<html>
     2.7 +  <head>
     2.8 +    <title>WebID 1.0</title>
     2.9 +    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
    2.10 +    <!-- 
    2.11 +      === NOTA BENE ===
    2.12 +      For the three scripts below, if your spec resides on dev.w3 you can check them
    2.13 +      out in the same tree and use relative links so that they'll work offline,
    2.14 +     -->
    2.15 +<style type='text/css'>
    2.16 +code           { font-family: monospace; }
    2.17 +
    2.18 +span.hilite { color: red; /* font-weight: bold */ }
    2.19 +
    2.20 +li p           { margin-top: 0.3em;
    2.21 +                 margin-bottom: 0.3em; }
    2.22 +
    2.23 +div.explanation { background-color: #ADD8E6;
    2.24 +                   width: 80%;
    2.25 +                   margin: 12px; padding: 8px; }
    2.26 +div.explanation li { margin-top: 8px; }
    2.27 +div.explanation dd { margin: 4px; }
    2.28 +
    2.29 +.adef { 
    2.30 +	font-family: monospace; 
    2.31 +	font-weight: bold; 
    2.32 +    color: #ff4500 !important;
    2.33 +}
    2.34 +
    2.35 +.aref { 
    2.36 +	font-family: monospace; 
    2.37 +	font-weight: bold; 
    2.38 +    color: #ff4500 !important;
    2.39 +}
    2.40 +
    2.41 +span.entity { color: red; }
    2.42 +
    2.43 +span.element { color: green; }
    2.44 +</style>
    2.45 +
    2.46 +    <script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script> 
    2.47 +<!--    <script src='/ReSpec.js/js/respec.js' class='remove'></script> -->
    2.48 +    <script class='remove'>
    2.49 +      var preProc = {
    2.50 +          apply:  function(c) {
    2.51 +                    // process the document before anything else is done
    2.52 +                    var refs = document.querySelectorAll('adef') ;
    2.53 +                    for (var i = 0; i < refs.length; i++) {
    2.54 +                        var item = refs[i];
    2.55 +                        var p = item.parentNode ;
    2.56 +                        var con = item.innerHTML ;
    2.57 +                        var sp = document.createElement( 'dfn' ) ;
    2.58 +                        var tit = item.getAttribute('title') ;
    2.59 +                        if (!tit) {
    2.60 +                            tit = con;
    2.61 +                        }
    2.62 +                        sp.className = 'adef' ;
    2.63 +                        sp.title=tit ;
    2.64 +                        sp.innerHTML = con ;
    2.65 +                        p.replaceChild(sp, item) ;
    2.66 +                    }
    2.67 +                    refs = document.querySelectorAll('aref') ;
    2.68 +                    for (var i = 0; i < refs.length; i++) {
    2.69 +                        var item = refs[i];
    2.70 +                        var p = item.parentNode ;
    2.71 +                        var con = item.innerHTML ;
    2.72 +                        var sp = document.createElement( 'a' ) ;
    2.73 +                        sp.className = 'aref' ;
    2.74 +                        sp.setAttribute('title', con);
    2.75 +                        sp.innerHTML = '@'+con ;
    2.76 +                        p.replaceChild(sp, item) ;
    2.77 +                    }
    2.78 +                    // local datatype references
    2.79 +                    refs = document.querySelectorAll('ldtref') ;
    2.80 +                    for (var i = 0; i < refs.length; i++) {
    2.81 +                        var item = refs[i];
    2.82 +                        if (!item) continue ;
    2.83 +                        var p = item.parentNode ;
    2.84 +                        var con = item.innerHTML ;
    2.85 +                        var ref = item.getAttribute('title') ;
    2.86 +                        if (!ref) {
    2.87 +                            ref = item.textContent ;
    2.88 +                        }
    2.89 +                        if (ref) {
    2.90 +                            ref = ref.replace(/\n/g, '_') ;
    2.91 +                            ref = ref.replace(/\s+/g, '_') ;
    2.92 +                        }
    2.93 +                        var sp = document.createElement( 'a' ) ;
    2.94 +                        sp.className = 'datatype';
    2.95 +                        sp.title = ref ;
    2.96 +                        sp.innerHTML = con ;
    2.97 +                        p.replaceChild(sp, item) ;
    2.98 +                    }
    2.99 +                    // external datatype references
   2.100 +                    refs = document.querySelectorAll('dtref') ;
   2.101 +                    for (var i = 0; i < refs.length; i++) {
   2.102 +                        var item = refs[i];
   2.103 +                        if (!item) continue ;
   2.104 +                        var p = item.parentNode ;
   2.105 +                        var con = item.innerHTML ;
   2.106 +                        var ref = item.getAttribute('title') ;
   2.107 +                        if (!ref) {
   2.108 +                            ref = item.textContent ;
   2.109 +                        }
   2.110 +                        if (ref) {
   2.111 +                            ref = ref.replace(/\n/g, '_') ;
   2.112 +                            ref = ref.replace(/\s+/g, '_') ;
   2.113 +                        }
   2.114 +                        var sp = document.createElement( 'a' ) ;
   2.115 +                        sp.className = 'externalDFN';
   2.116 +                        sp.title = ref ;
   2.117 +                        sp.innerHTML = con ;
   2.118 +                        p.replaceChild(sp, item) ;
   2.119 +                    }
   2.120 +                    // now do terms
   2.121 +                    refs = document.querySelectorAll('tdef') ;
   2.122 +                    for (var i = 0; i < refs.length; i++) {
   2.123 +                        var item = refs[i];
   2.124 +                        if (!item) continue ;
   2.125 +                        var p = item.parentNode ;
   2.126 +                        var con = item.innerHTML ;
   2.127 +                        var ref = item.getAttribute('title') ;
   2.128 +                        if (!ref) {
   2.129 +                            ref = item.textContent ;
   2.130 +                        }
   2.131 +                        if (ref) {
   2.132 +                            ref = ref.replace(/\n/g, '_') ;
   2.133 +                            ref = ref.replace(/\s+/g, '_') ;
   2.134 +                        }
   2.135 +                        var sp = document.createElement( 'dfn' ) ;
   2.136 +                        sp.title = ref ;
   2.137 +                        sp.innerHTML = con ;
   2.138 +                        p.replaceChild(sp, item) ;
   2.139 +                    }
   2.140 +                    // now term references
   2.141 +                    refs = document.querySelectorAll('tref') ;
   2.142 +                    for (var i = 0; i < refs.length; i++) {
   2.143 +                        var item = refs[i];
   2.144 +                        if (!item) continue ;
   2.145 +                        var p = item.parentNode ;
   2.146 +                        var con = item.innerHTML ;
   2.147 +                        var ref = item.getAttribute('title') ;
   2.148 +                        if (!ref) {
   2.149 +                            ref = item.textContent ;
   2.150 +                        }
   2.151 +                        if (ref) {
   2.152 +                            ref = ref.replace(/\n/g, '_') ;
   2.153 +                            ref = ref.replace(/\s+/g, '_') ;
   2.154 +                        }
   2.155 +
   2.156 +                        var sp = document.createElement( 'a' ) ;
   2.157 +                        var id = item.textContent ;
   2.158 +                        sp.className = 'tref' ;
   2.159 +                        sp.title = ref ;
   2.160 +                        sp.innerHTML = con ;
   2.161 +                        p.replaceChild(sp, item) ;
   2.162 +                    }
   2.163 +                }
   2.164 +        } ;
   2.165 +
   2.166 +
   2.167 +      var respecConfig = {
   2.168 +          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
   2.169 +          // embed RDFa data in the output
   2.170 +          doRDFa: true,
   2.171 +          specStatus:           "unofficial",
   2.172 +          //publishDate:          "2010-07-05",
   2.173 +          diffTool:             "http://www3.aptest.com/standards/htmldiff/htmldiff.pl",
   2.174 +          
   2.175 +          // the specifications short name, as in http://www.w3.org/TR/short-name/
   2.176 +          shortName:            "webid",
   2.177 +          subtitle: "Web Identification and Discovery",
   2.178 +
   2.179 +          // if you wish the publication date to be other than today, set this
   2.180 +          // publishDate:  "2009-08-06",
   2.181 +          copyrightStart:  "2010",
   2.182 +
   2.183 +          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
   2.184 +          // and its maturity status
   2.185 +          //previousPublishDate:  "2010-04-22",
   2.186 +          //previousMaturity:  "FPWD",
   2.187 +
   2.188 +
   2.189 +          // if there a publicly available Editors Draft, this is the link
   2.190 +          edDraftURI:           "http://payswarm.com/webid/",
   2.191 +
   2.192 +          // if this is a LCWD, uncomment and set the end of its review period
   2.193 +          // lcEnd: "2009-08-05",
   2.194 +
   2.195 +          // if you want to have extra CSS, append them to this list
   2.196 +          // it is recommended that the respec.css stylesheet be kept
   2.197 +          extraCSS:             ['http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css'],
   2.198 +
   2.199 +          // editors, add as many as you like
   2.200 +          // only "name" is required
   2.201 +          editors:  [
   2.202 +              { name: "Manu Sporny", mailto:"msporny@digitalbazaar.com",
   2.203 +                  company: "Digital Bazaar, Inc.", companyURL: "http://blog.digitalbazaar.com/" }
   2.204 +              ],
   2.205 +
   2.206 +          // authors, add as many as you like. 
   2.207 +          // This is optional, uncomment if you have authors as well as editors.
   2.208 +          // only "name" is required. Same format as editors.
   2.209 +
   2.210 +          authors:  [
   2.211 +              { name: "Toby Inkster" },
   2.212 +              { name: "Henry Story", url: "http://bblfish.net/" }
   2.213 +          ],
   2.214 +
   2.215 +//          errata: 'http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata',
   2.216 +          
   2.217 +          // name of the WG
   2.218 +          wg:           "Social Web XG",
   2.219 +          
   2.220 +          // URI of the public WG page
   2.221 +          wgURI:        "http://esw.w3.org/Foaf%2Bssl",
   2.222 +          
   2.223 +          // name (with the @w3c.org) of the public mailing to which comments are due
   2.224 +          wgPublicList: "socialweb-xg",
   2.225 +          
   2.226 +          // URI of the patent status for this WG, for Rec-track documents
   2.227 +          // !!!! IMPORTANT !!!!
   2.228 +          // This is important for Rec-track documents, do not copy a patent URI from a random
   2.229 +          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
   2.230 +          // Team Contact.
   2.231 +          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/44350/status",
   2.232 +          maxTocLevel: 4,
   2.233 +          preProcess: [ preProc ] 
   2.234 +      };
   2.235 +
   2.236 +
   2.237 +      function updateExample(doc, content) {
   2.238 +        // perform transformations to make it render and prettier
   2.239 +        content = content.replace(/<!--/, '');
   2.240 +        content = content.replace(/-->/, '');
   2.241 +        content = doc._esc(content);
   2.242 +        content = content.replace(/\*\*\*\*([^*]*)\*\*\*\*/g, '<span class="hilite">$1</span>') ;
   2.243 +        return content ;
   2.244 +      }
   2.245 +
   2.246 +      function updateDTD(doc, content) {
   2.247 +        // perform transformations to 
   2.248 +        // make it render and prettier
   2.249 +        content = '<pre class="dtd">' + doc._esc(content) + '</pre>';
   2.250 +        content = content.replace(/!ENTITY % ([^ \t\r\n]*)/g, '!ENTITY <span class="entity">% $1</span>');
   2.251 +        content = content.replace(/!ELEMENT ([^ \t$]*)/mg, '!ELEMENT <span class="element">$1</span>');
   2.252 +        return content;
   2.253 +      }
   2.254 +
   2.255 +      function updateSchema(doc, content) {
   2.256 +        // perform transformations to 
   2.257 +        // make it render and prettier
   2.258 +        content = '<pre class="dtd">' + doc._esc(content) + '</pre>';
   2.259 +        content = content.replace(/&lt;xs:element\s+name=&quot;([^&]*)&quot;/g, '&lt;xs:element name="<span class="element" id="schema_element_$1">$1</span>"') ;
   2.260 +        return content;
   2.261 +      }
   2.262 +
   2.263 +      function updateTTL(doc, content) {
   2.264 +        // perform transformations to 
   2.265 +        // make it render and prettier
   2.266 +        content = '<pre class="sh_sourceCode">' + doc._esc(content) + '</pre>';
   2.267 +        content = content.replace(/@prefix/g, '<span class="sh_keyword">@prefix</span>');
   2.268 +        return content;
   2.269 +      }
   2.270 +    </script>
   2.271 +  </head>
   2.272 +  <body>
   2.273 +    <section id='abstract'>
   2.274 +
   2.275 +<p>Privacy and Identification on the Web have been at the center of how we
   2.276 +interact with sites on the Web. The explosion of Websites over the last decade
   2.277 +and a half has created a point of pain for anyone that uses the Web on a
   2.278 +regular basis. Remembering login details, passwords,
   2.279 +and sharing private information across the many websites that people use on a
   2.280 +daily basis has become more difficult and complicated than necessary. This 
   2.281 +specification outlines a simple universal identification mechanism that is
   2.282 +distributed, openly extensible, improves privacy, security and control over how 
   2.283 +one can identify themselves on the Web.</p>
   2.284 +  
   2.285 +<section>
   2.286 +<h2>How to Read this Document</h2>
   2.287 +  
   2.288 +<p>There are a number of concepts that are covered in this document that the
   2.289 +reader may want to be aware of before continuing. General knowledge of
   2.290 +<a href="http://en.wikipedia.org/wiki/Public_key_cryptography">public key cryptography</a> 
   2.291 +is necessary to understand how to implement this specification. 
   2.292 +WebID also uses HTTP over TLS [[!HTTP-TLS]], X.509 certificates
   2.293 +[[!X509V3]], and RDFa [[!RDFA-CORE]].</p>
   2.294 +
   2.295 +<p>A general <a href="#introduction">Introduction</a> is provided for all that
   2.296 +would like to understand why this specification is necessary to simplify usage
   2.297 +of the Web.</p>
   2.298 +
   2.299 +<p>The terms used throughout this specification are listed in the section
   2.300 +titled <a href="#terminology">Terminology</a>.</p>
   2.301 +
   2.302 +<p>Developers that are interested in implementing this specification will be
   2.303 +most interested in the sections titled 
   2.304 +<a href="#authentication-sequence">Authentication Sequence</a> and 
   2.305 +<a href="#authentication-sequence-details">Authentication Sequence Details</a>.
   2.306 +  
   2.307 +</section>
   2.308 +</section>
   2.309 +
   2.310 +<section id='sotd'>
   2.311 +<!-- <p>This document has been reviewed by W3C Members, by software
   2.312 +developers, and by other W3C groups and interested parties, and is
   2.313 +endorsed by the Director as a W3C Recommendation. It is a stable
   2.314 +document and may be used as reference material or cited from another
   2.315 +document. W3C's role in making the Recommendation is to draw attention
   2.316 +to the specification and to promote its widespread deployment. This
   2.317 +enhances the functionality and interoperability of the Web.</p> -->
   2.318 +
   2.319 +</section>
   2.320 +
   2.321 +<section class='informative'>
   2.322 +<h1>Introduction</h1>
   2.323 +
   2.324 +<p>
   2.325 +The WebID specification is designed to help alleviate the difficultly that
   2.326 +remembering different logins, passwords and settings for websites has created. 
   2.327 +It is also designed to provide a universal and extensible mechanism to express 
   2.328 +public and private information about yourself. This section outlines the 
   2.329 +motivation behind the specification and the relationship to other similar 
   2.330 +specifications that are in active use today.
   2.331 +</p>
   2.332 +
   2.333 +<section class='informative'>
   2.334 +<h1>Motivation</h1>
   2.335 +
   2.336 +<p>
   2.337 +It is a fundamental design criteria of the Web to enable individuals and
   2.338 +organizations to control how they interact with the rest of society. This
   2.339 +includes how one expresses their identity, public information and personal 
   2.340 +details to social networks, Web sites and services.
   2.341 +</p>
   2.342 +
   2.343 +<p>
   2.344 +Semantic Web vocabularies such as Friend-of-a-Friend (FOAF) permit distributed 
   2.345 +hyperlinked social networks to exist. This vocabulary, along with other 
   2.346 +vocabularies, allow one to add information and services protection to 
   2.347 +distributed social networks.
   2.348 +</p>
   2.349 +
   2.350 +<p>
   2.351 +One major criticism of open networks is that they seem to have no way of
   2.352 +protecting the personal information distributed on the web or limiting
   2.353 +access to resources. Few people are willing to make all their personal
   2.354 +information public, many would like large pieces to be protected, making
   2.355 +it available only to a select group of agents. Giving access to
   2.356 +information is very similar to giving access to services. There are many
   2.357 +occasions when people would like services to only be accessible to
   2.358 +members of a group, such as allowing only friends, family members,
   2.359 +colleagues to post an article, photo or comment on a blog. How does one do
   2.360 +this in a flexible way, without requiring a central point of
   2.361 +access control?
   2.362 +</p>
   2.363 +
   2.364 +<p>
   2.365 +Using an process made popular by OpenID, we show how one can tie a User
   2.366 +Agent to a URL by proving that one has write access to the URL. WebID is
   2.367 +a simpler alternative to OpenID (fewer connections), that uses X.509 
   2.368 +certificates to tie a User Agent (Browser) to a Person identified via a URL. 
   2.369 +WebID also provides a few additional features to OpenID. These
   2.370 +features include trust management, via digital signatures, and free-form 
   2.371 +extensibility via RDFa. By using the existing SSL certificate exchange
   2.372 +mechanism, WebID integrates more smoothly with existing Web browsers, including
   2.373 +browsers on mobile devices. WebID also permits automated session login
   2.374 +in addition to interactive session login. Additionally, all data is encrypted
   2.375 +and guaranteed to only be received by the person or organization that was 
   2.376 +intended to receive it.
   2.377 +</p>
   2.378 +
   2.379 +</section>
   2.380 +
   2.381 +<section class='informative'>
   2.382 +<h1>Relation to OpenID</h1>
   2.383 +
   2.384 +<p>While some may say that OpenID and WebID conflict, WebID is 100% compatible
   2.385 +with OpenID since both use a URL for identification. Therefore, WebID does not
   2.386 +intend to replace OpenID, but can work beside OpenID just as easily as providing
   2.387 +a complete solution. That said, there are a number of benefits that WebID
   2.388 +achieves over OpenID:
   2.389 +</p>
   2.390 +
   2.391 +<p>WebID gives people and other agents a Web ID URL for identification, just
   2.392 +like OpenId does. However, in the case of WebID, the user does not need to
   2.393 +remember the URL, the browser or User Agent does. A login button on a
   2.394 +WebID web site is just a button. No need to enter any identifier like one
   2.395 +has to for OpenID. Just click the button. Your browser will then ask you what 
   2.396 +identity you wish to use. The person that is browsing does not need to 
   2.397 +remember either the WebID URL or the website password. The only password one
   2.398 +needs to remember is the one that is used to access their collection of
   2.399 +WebIDs in their browser.</p>
   2.400 +
   2.401 +<p>The WebID protocol requires just one direct network connection to establish
   2.402 +identity via the client. The server requires one connection to the client and
   2.403 +one connection to retrieve the WebID URL if it does not have the credential
   2.404 +information cached. Compare this to the much more complex OpenID sequence, which
   2.405 +requires six connections by the client to establish a login. In a world of 
   2.406 +distributed data where each site can point to data on any other site, multiple 
   2.407 +connections become costly to manage.</p>
   2.408 +
   2.409 +<p>WebID builds on well established Internet and Web standards;
   2.410 +<a href="http://en.wikipedia.org/wiki/REST">REST</a>, 
   2.411 +RDF [[RDF-PRIMER]], RDFa [[!RDFA-CORE]], TLS [[!HTTP-TLS]], and X.509 
   2.412 +[[!X509V3]]. By building on previous standards, it makes both explaining and 
   2.413 +implementing WebID easier on developers.</p>
   2.414 +
   2.415 +<p>Since WebID is RESTful, you can perform basic HTTP operations to 
   2.416 +<code>GET</code> your WebID, and if you needed update it, you can use
   2.417 +HTTP <code>PUT</code> semantics. You can also create a WebID via 
   2.418 +<code>POST</code>. This is improved from the OpenID specification, which
   2.419 +requires a new set of operations described in the OpenID Attribute Exchange
   2.420 +specification.</p>
   2.421 +
   2.422 +<p>It is easy to extend a WebID with new attributes via RDF. The power of
   2.423 +RDF and RDFa allows developers to add extensions to WebID by defining new
   2.424 +vocabularies that they publish. There is no authorization process necessary
   2.425 +and thus WebID allows for distributed innovation. Every WebID property is
   2.426 +a URI, which when clicked, can give you yet more information about what the
   2.427 +property means. A developer can create new usage classes by extending their
   2.428 +vocabulary at will. A developer can add relationships to a WebID by simply
   2.429 +adding more HTML to the developer's page. OpenID does not provide any type of
   2.430 +distributed innovation akin to RDF or RDFa.</p>
   2.431 +
   2.432 +<p>WebID is built on RDF and thus enables all of the advanced semantic web
   2.433 +concepts that RDF enables. For example, a developer may perform machine
   2.434 +reasoning with a WebID. One can construct machine-executable statements like
   2.435 +"If this WebID claims to be a friend of one of our partner WebIDs that is
   2.436 +trusted and the relationship is bi-directional, trust the WebID." 
   2.437 +While OpenID attempts to support this use case by mapping OpenID to RDF, it's
   2.438 +far easier to do with WebID because WebID is natively RDF-aware.</p>
   2.439 +
   2.440 +<p>Implementing WebID is easier than OpenID because all of the basic 
   2.441 +technologies have been working and integrated into Web browsers for many years. 
   2.442 +There were already three interoperable implementations of WebID before this 
   2.443 +specification was written.</p>
   2.444 +
   2.445 +<p>WebID is truly decentralized - with WebID you get a web of trust. 
   2.446 +OpenID only supports the Web of Trust model if you indirectly trust the
   2.447 +OpenID provider. In other words - OpenID is not truly decentralized. In OpenID
   2.448 +you must trust OpenID providers. With WebID you only have to trust the people
   2.449 +and the organizations with which you are communicating. In other words, you
   2.450 +don't have to ask anyone whether or not you can trust your friends. You can
   2.451 +query people that you trust directly to see if someone is trustworthy or not.
   2.452 +There is no need for a central WebID authority.
   2.453 +</p>
   2.454 +
   2.455 +<p>WebID is fully distributed, anyone can setup a WebID by placing a single
   2.456 +file on a web server of their choosing. There is no need for a special 
   2.457 +OpenID-like provider service. The only thing anyone that wants a WebID needs
   2.458 +is a web account where you can post your WebID file, ideally on your own domain 
   2.459 +name. You can also use a WebID hosting provider, but it's not necessary for
   2.460 +WebID to work. While it is possible to run an OpenID server, other
   2.461 +OpenID applications may not trust you and thus you won't be able to fully
   2.462 +utilize your private OpenID credentials. The reason that there are a few
   2.463 +large OpenID providers and very few small OpenID providers is because of this
   2.464 +trust design issue related to OpenID.</p>
   2.465 +
   2.466 +<p>WebID does not require HTTP redirects. Redirects are are problematic on many
   2.467 +cell phones, because telecoms heavily rely on proxys, which selectively block
   2.468 +redirects.</p>
   2.469 +
   2.470 +<p>A WebID provider is 100% compatible with an OpenID provider and thus can 
   2.471 +inter-operate with OpenID-powered networks.</p>
   2.472 +
   2.473 +</section>
   2.474 +
   2.475 +<section class='informative'>
   2.476 +<h1>Relation to OAuth</h1>
   2.477 +
   2.478 +<p>
   2.479 +OAuth and WebID are mutually beneficial when used together. WebID can be
   2.480 +used to provide RSA parameters to the RSA-SHA1 signature method required by
   2.481 +OAuth 1.0. WebID can also be used to establish the consumer_key and HTTPS 
   2.482 +connection that will be used to transmit OAuth Tokens in OAuth 2.0.
   2.483 +</p>
   2.484 +
   2.485 +</section>
   2.486 +</section>
   2.487 +
   2.488 +<section class='normative'>
   2.489 +<h1>The WebID Protocol</h1>
   2.490 +
   2.491 +<section class='normative'>
   2.492 +<h1>Terminology</h1>
   2.493 +
   2.494 +<dl>
   2.495 +<dt><tdef>Verification Agent</tdef></dt>
   2.496 +<dd>Performs authentication on provided WebID credentials and determines if
   2.497 +an <tref>Identification Agent</tref> can have access to a particular 
   2.498 +resource. A <tref>Verification Agent</tref> is typically a Web server, but 
   2.499 +may also be a peer on a peer-to-peer network.</dd>
   2.500 +<dt><tdef>Identification Agent</tdef></dt>
   2.501 +<dd>Provides identification credentials to a Verification Agent. The
   2.502 +<tref>Identification Agent</tref> is typically also a User Agent.</dd>
   2.503 +<dt><tdef>Identification Certificate</tdef></dt>
   2.504 +<dd>An X.509 [[!X509V3]] Certificate that MUST contain the 
   2.505 +<code>Subject Alternative Name</code> field pointing to a URL that is
   2.506 +dereference-able and results in an [[!XHTML-RDFA]] document. For example 
   2.507 +the certificate would contain <code>http://example.org/webid#public</code> as
   2.508 +the <code>Subject Alternative Name</code>:
   2.509 +<code><pre>
   2.510 +X509v3 extensions:
   2.511 +   ...
   2.512 +   X509v3 Subject Alternative Name:
   2.513 +      URI:http://example.org/webid#public
   2.514 +</pre></code>
   2.515 +<dt><tdef>WebID URL</tdef></dt>
   2.516 +<dd>The URL that contains identification credentials for the 
   2.517 +<tref>Identification Agent</tref> encoded in RDFa [[!XHTML-RDFA]].</dd>
   2.518 +</dd>
   2.519 +</dl>
   2.520 +
   2.521 +</section>
   2.522 +
   2.523 +<section class='normative'>
   2.524 +<h1>Authentication Sequence</h1>
   2.525 +
   2.526 +<p>The following steps are executed by Verification Agents and Identification
   2.527 +Agents to determine if access should be granted to a particular resource.
   2.528 +</p>
   2.529 +
   2.530 +<ol>
   2.531 +<li>The <tref>Identification Agent</tref> attempts to access a resource
   2.532 +using HTTP over TLS [[!HTTP-TLS]] via the <tref>Verification Agent</tref>.</li>
   2.533 +
   2.534 +<li>The <tref>Verification Agent</tref> MUST request the 
   2.535 +<tref>Identification Certificate</tref> of the <tref>Identification Agent</tref>
   2.536 +as a part of the TLS client-cerificate retrieval protocol.</li>
   2.537 +
   2.538 +<li>The <tref>Verification Agent</tref> MUST extract the <tref>WebID URL</tref> 
   2.539 +contained in the <code>Subject Alternative Name</code> field of the 
   2.540 +<tref>Identification Certificate</tref>. The <tref>WebID URL</tref> MUST be 
   2.541 +dereferenced and the resulting document processed according to [[!XHTML-RDFA]]. 
   2.542 +All triples pertaining to the public key associated with the 
   2.543 +<tref>WebID URL</tref> MUST be extracted from the remote document.</li>
   2.544 +
   2.545 +<li>The remote document triples MUST be queried for information about the 
   2.546 +public key contained in the <tref>Identification Certificate</tref>. 
   2.547 +If the public key in the certificate is found in the list of public keys 
   2.548 +associated with the <tref>WebID URL</tref>, the <tref>Verification Agent</tref>
   2.549 +MUST assume that the client has write access to the <tref>WebID URL</tref> and
   2.550 +therefore owns the URL.</li>
   2.551 +
   2.552 +<li>At this point, the <tref>Verification Agent</tref> has verified that the
   2.553 +<tref>WebID URL</tref> is owned by the <tref>Identification Agent</tref>. The
   2.554 +<tref>Verification Agent</tref> MUST use the now verified public key contained 
   2.555 +in the <tref>Identification Certificate</tref> for all TLS-based communication
   2.556 +with the <tref>Identification Agent</tref>.
   2.557 +</ol>
   2.558 +
   2.559 +<p>
   2.560 +The <tref>Identification Agent</tref> MAY re-establish a different identity at 
   2.561 +any time by executing all of the steps in the Authentication Sequence again. 
   2.562 +Additional algorithms, detailed in the next section, MAY be performed to 
   2.563 +determine if the <tref>Verification Agent</tref> can access a particular 
   2.564 +resource after the last step of the Authentication Sequence has been
   2.565 +completed.</li>
   2.566 +</p>
   2.567 +
   2.568 +</section>
   2.569 +
   2.570 +<section class='normative'>
   2.571 +<h1>Authentication Sequence Details</h1>
   2.572 +
   2.573 +<p>This section covers details about each step in the authentication process.
   2.574 +</p>
   2.575 +
   2.576 +<section class='normative'>
   2.577 +<h2>Initiating a TLS Connection</h2>
   2.578 +
   2.579 +<p class="issue">This section will detail how the TLS connection process is
   2.580 +started and used by WebID to create a secure channel between the 
   2.581 +Identification Agent and the Verification Agent.</p>
   2.582 +</section>
   2.583 +
   2.584 +<section class='normative'>
   2.585 +<h2>Exchanging the Identification Certificate</h2>
   2.586 +
   2.587 +<p class="issue">This section will detail how the certificate is selected and
   2.588 +sent to the Verification Agent.</p>
   2.589 +</section>
   2.590 +
   2.591 +<section class='normative'>
   2.592 +<h2>Processing the WebID URL</h2>
   2.593 +
   2.594 +<p class="issue">This section will explain how a Verification Agent extracts 
   2.595 +semantic data describing the identification credentials from a WebID URL.</p>
   2.596 +</section>
   2.597 +
   2.598 +<section class='normative'>
   2.599 +<h2>Extracting Identification URL Details</h2>
   2.600 +
   2.601 +<p>
   2.602 +The <tref>Verification Agent</tref> may use a number of different methods to
   2.603 +extract the public key information from the <tref>WebID URL</tref>.
   2.604 +</p>
   2.605 +The following SPARQL query outlines one way in which the public key
   2.606 +could be extracted from the <tref>WebID URL</tref>:
   2.607 +<code><pre>
   2.608 +PREFIX cert: &lt;http://www.w3.org/ns/auth/cert#&gt;
   2.609 +PREFIX rsa: &lt;http://www.w3.org/ns/auth/rsa#&gt;
   2.610 +SELECT ?modulus ?exp
   2.611 +WHERE {
   2.612 +   ?key cert:identity &lt;http://example.org/webid#public&gt;;
   2.613 +      a rsa:RSAPublicKey;
   2.614 +      rsa:modulus [ cert:hex ?modulus; ];
   2.615 +      rsa:public_exponent [ cert:decimal ?exp ] .
   2.616 +}
   2.617 +</pre></code>
   2.618 +
   2.619 +<p class="issue">This section still needs more information.</p>
   2.620 +
   2.621 +</section>
   2.622 +
   2.623 +<section class='normative'>
   2.624 +<h2>Determining Access Privileges</h2>
   2.625 +
   2.626 +<p class="issue">This section will explain how a Verification Agent may
   2.627 +use the information discovered via a WebID URL to determine if one should
   2.628 +be able to access a particular resource. It will explain how a Verification
   2.629 +Agent can use links to other RDFa documents to build knowledge about the
   2.630 +given WebID.</p>
   2.631 +
   2.632 +</section>
   2.633 +
   2.634 +</section>
   2.635 +
   2.636 +<section id="appendix">
   2.637 +
   2.638 +<section class='informative' id="history">
   2.639 +<h1 >Change History</h1>
   2.640 +<p>2010-07-11 Initial version.</p>
   2.641 +</section>
   2.642 +
   2.643 +<section class='informative' id="acknowledgements">
   2.644 +<h1>Acknowledgments</h1>
   2.645 +
   2.646 +<p>The following people have been instrumental in providing thoughts, feedback,
   2.647 +reviews, criticism and input in the creation of this specification:</p>
   2.648 +
   2.649 +<ul>
   2.650 +<li>Melvin Carvalho</li>
   2.651 +<li>Bruno Harbulot</li>
   2.652 +<li>Toby Inkster</li>
   2.653 +<li>Ian Jacobi</li>
   2.654 +<li>Jeff Sayre</li>
   2.655 +<li>Henry Story</li>
   2.656 +</ul>
   2.657 +
   2.658 +</section>
   2.659 +</section>
   2.660 +  </body>
   2.661 +</html>
   2.662 +
     3.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.2 +++ b/index.html	Sun Jul 11 16:40:42 2010 -0400
     3.3 @@ -0,0 +1,460 @@
     3.4 +<?xml version='1.0' encoding='UTF-8'?>
     3.5 +<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML+RDFa 1.0//EN' 'http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd'>
     3.6 +<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#'>
     3.7 +<head>
     3.8 +    <title>WebID 1.0</title>
     3.9 +    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    3.10 +    
    3.11 +<!--  
    3.12 +      === NOTA BENE ===
    3.13 +      For the three scripts below, if your spec resides on dev.w3 you can check them
    3.14 +      out in the same tree and use relative links so that they'll work offline,
    3.15 +      -->
    3.16 +
    3.17 +<style type="text/css">
    3.18 +code           { font-family: monospace; }
    3.19 +
    3.20 +span.hilite { color: red; /* font-weight: bold */ }
    3.21 +
    3.22 +li p           { margin-top: 0.3em;
    3.23 +                 margin-bottom: 0.3em; }
    3.24 +
    3.25 +div.explanation { background-color: #ADD8E6;
    3.26 +                   width: 80%;
    3.27 +                   margin: 12px; padding: 8px; }
    3.28 +div.explanation li { margin-top: 8px; }
    3.29 +div.explanation dd { margin: 4px; }
    3.30 +
    3.31 +.adef { 
    3.32 +	font-family: monospace; 
    3.33 +	font-weight: bold; 
    3.34 +    color: #ff4500 !important;
    3.35 +}
    3.36 +
    3.37 +.aref { 
    3.38 +	font-family: monospace; 
    3.39 +	font-weight: bold; 
    3.40 +    color: #ff4500 !important;
    3.41 +}
    3.42 +
    3.43 +span.entity { color: red; }
    3.44 +
    3.45 +span.element { color: green; }
    3.46 +</style>
    3.47 +
    3.48 +     
    3.49 +
    3.50 +<!--     <script src='/ReSpec.js/js/respec.js' class='remove'></script>  -->
    3.51 +
    3.52 +    
    3.53 +  <link href="http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css" rel="stylesheet" type="text/css" charset="utf-8" /><link href="http://www.w3.org/StyleSheets/TR/w3c-unofficial" rel="stylesheet" type="text/css" charset="utf-8" /></head><body style="display: inherit; "><div class="head"><p></p><h1 rel="dcterms:title" class="title" id="title">WebID 1.0</h1><h2 rel="bibo:subtitle" id="subtitle">Web Identification and Discovery</h2><h2 property="dcterms:issued" datatype="xsd:dateTime" content="2010-07-11T20:21:06+0000" id="unofficial-draft-11-july-2010">Unofficial Draft 11 July 2010</h2><dl><dt>Editor:</dt><dd rel="bibo:editor"><span typeof="foaf:Person"><span property="foaf:name">Manu Sporny</span>, <a rel="foaf:workplaceHomepage" href="http://blog.digitalbazaar.com/">Digital Bazaar, Inc.</a> <a rel="foaf:mbox" href="mailto:msporny@digitalbazaar.com">msporny@digitalbazaar.com</a> </span>
    3.54 +</dd>
    3.55 +<dt>Authors:</dt><dd><span><span>Toby Inkster</span></span>
    3.56 +</dd>
    3.57 +<dd><span><a content="Henry Story" href="http://bblfish.net/">Henry Story</a></span>
    3.58 +</dd>
    3.59 +</dl><p class="copyright">This document is licensed under a <a class="subfoot" href="http://creativecommons.org/licenses/by/3.0/" rel="license">Creative Commons Attribution 3.0 License</a>.</p><hr></hr></div>
    3.60 +    <div id="abstract" class="introductory section" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" about="#abstract"><h2>Abstract</h2>
    3.61 +
    3.62 +<p>Privacy and Identification on the Web have been at the center of how we
    3.63 +interact with sites on the Web. The explosion of Websites over the last decade
    3.64 +and a half has created a point of pain for anyone that uses the Web on a
    3.65 +regular basis. Remembering login details, passwords,
    3.66 +and sharing private information across the many websites that people use on a
    3.67 +daily basis has become more difficult and complicated than necessary. This 
    3.68 +specification outlines a simple universal identification mechanism that is
    3.69 +distributed, openly extensible, improves privacy, security and control over how 
    3.70 +one can identify themselves on the Web.</p>
    3.71 +  
    3.72 +<div typeof="bibo:Chapter" about="#how-to-read-this-document" class="section">
    3.73 +<h3 id="how-to-read-this-document">How to Read this Document</h3>
    3.74 +  
    3.75 +<p>There are a number of concepts that are covered in this document that the
    3.76 +reader may want to be aware of before continuing. General knowledge of
    3.77 +<a href="http://en.wikipedia.org/wiki/Public_key_cryptography">public key cryptography</a> 
    3.78 +is necessary to understand how to implement this specification. 
    3.79 +WebID also uses HTTP over TLS [<a class="bibref" rel="biblioentry" href="#bib-HTTP-TLS">HTTP-TLS</a>], X.509 certificates
    3.80 +[<a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a>], and RDFa [<a class="bibref" rel="biblioentry" href="#bib-RDFA-CORE">RDFA-CORE</a>].</p>
    3.81 +
    3.82 +<p>A general <a href="#introduction">Introduction</a> is provided for all that
    3.83 +would like to understand why this specification is necessary to simplify usage
    3.84 +of the Web.</p>
    3.85 +
    3.86 +<p>The terms used throughout this specification are listed in the section
    3.87 +titled <a href="#terminology">Terminology</a>.</p>
    3.88 +
    3.89 +<p>Developers that are interested in implementing this specification will be
    3.90 +most interested in the sections titled 
    3.91 +<a href="#authentication-sequence">Authentication Sequence</a> and 
    3.92 +<a href="#authentication-sequence-details">Authentication Sequence Details</a>.
    3.93 +  
    3.94 +</p></div>
    3.95 +</div><div id="sotd" class="introductory section" typeof="bibo:Chapter" about="#sotd"><h2>Status of This Document</h2><p>This document is merely a public working draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.</p>
    3.96 +
    3.97 +<!--  <p>This document has been reviewed by W3C Members, by software
    3.98 +developers, and by other W3C groups and interested parties, and is
    3.99 +endorsed by the Director as a W3C Recommendation. It is a stable
   3.100 +document and may be used as reference material or cited from another
   3.101 +document. W3C's role in making the Recommendation is to draw attention
   3.102 +to the specification and to promote its widespread deployment. This
   3.103 +enhances the functionality and interoperability of the Web.</p>  -->
   3.104 +
   3.105 +
   3.106 +</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="#motivation" class="tocxref"><span class="secno">1.1 </span>Motivation</a></li><li class="tocline"><a href="#relation-to-openid" class="tocxref"><span class="secno">1.2 </span>Relation to OpenID</a></li><li class="tocline"><a href="#relation-to-oauth" class="tocxref"><span class="secno">1.3 </span>Relation to OAuth</a></li></ul></li><li class="tocline"><a href="#the-webid-protocol" class="tocxref"><span class="secno">2. </span>The WebID Protocol</a><ul class="toc"><li class="tocline"><a href="#terminology" class="tocxref"><span class="secno">2.1 </span>Terminology</a></li><li class="tocline"><a href="#authentication-sequence" class="tocxref"><span class="secno">2.2 </span>Authentication Sequence</a></li><li class="tocline"><a href="#authentication-sequence-details" class="tocxref"><span class="secno">2.3 </span>Authentication Sequence Details</a><ul class="toc"><li class="tocline"><a href="#initiating-a-tls-connection" class="tocxref"><span class="secno">2.3.1 </span>Initiating a TLS Connection</a></li><li class="tocline"><a href="#exchanging-the-identification-certificate" class="tocxref"><span class="secno">2.3.2 </span>Exchanging the Identification Certificate</a></li><li class="tocline"><a href="#processing-the-webid-url" class="tocxref"><span class="secno">2.3.3 </span>Processing the WebID URL</a></li><li class="tocline"><a href="#extracting-identification-url-details" class="tocxref"><span class="secno">2.3.4 </span>Extracting Identification URL Details</a></li><li class="tocline"><a href="#determining-access-privileges" class="tocxref"><span class="secno">2.3.5 </span>Determining Access Privileges</a></li></ul></li></ul></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">A. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">A.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">A.2 </span>Informative references</a></li></ul></li></ul></div>
   3.107 +
   3.108 +
   3.109 +
   3.110 +<div class="informative section" id="introduction" typeof="bibo:Chapter" about="#introduction">
   3.111 +
   3.112 +<!-- OddPage -->
   3.113 +<h2><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
   3.114 +
   3.115 +<p>
   3.116 +The WebID specification is designed to help alleviate the difficultly that
   3.117 +remembering different logins, passwords and settings for websites has created. 
   3.118 +It is also designed to provide a universal and extensible mechanism to express 
   3.119 +public and private information about yourself. This section outlines the 
   3.120 +motivation behind the specification and the relationship to other similar 
   3.121 +specifications that are in active use today.
   3.122 +</p>
   3.123 +
   3.124 +<div class="informative section" id="motivation" typeof="bibo:Chapter" about="#motivation">
   3.125 +<h3><span class="secno">1.1 </span>Motivation</h3><p><em>This section is non-normative.</em></p>
   3.126 +
   3.127 +<p>
   3.128 +It is a fundamental design criteria of the Web to enable individuals and
   3.129 +organizations to control how they interact with the rest of society. This
   3.130 +includes how one expresses their identity, public information and personal 
   3.131 +details to social networks, Web sites and services.
   3.132 +</p>
   3.133 +
   3.134 +<p>
   3.135 +Semantic Web vocabularies such as Friend-of-a-Friend (FOAF) permit distributed 
   3.136 +hyperlinked social networks to exist. This vocabulary, along with other 
   3.137 +vocabularies, allow one to add information and services protection to 
   3.138 +distributed social networks.
   3.139 +</p>
   3.140 +
   3.141 +<p>
   3.142 +One major criticism of open networks is that they seem to have no way of
   3.143 +protecting the personal information distributed on the web or limiting
   3.144 +access to resources. Few people are willing to make all their personal
   3.145 +information public, many would like large pieces to be protected, making
   3.146 +it available only to a select group of agents. Giving access to
   3.147 +information is very similar to giving access to services. There are many
   3.148 +occasions when people would like services to only be accessible to
   3.149 +members of a group, such as allowing only friends, family members,
   3.150 +colleagues to post an article, photo or comment on a blog. How does one do
   3.151 +this in a flexible way, without requiring a central point of
   3.152 +access control?
   3.153 +</p>
   3.154 +
   3.155 +<p>
   3.156 +Using an process made popular by OpenID, we show how one can tie a User
   3.157 +Agent to a URL by proving that one has write access to the URL. WebID is
   3.158 +a simpler alternative to OpenID (fewer connections), that uses X.509 
   3.159 +certificates to tie a User Agent (Browser) to a Person identified via a URL. 
   3.160 +WebID also provides a few additional features to OpenID. These
   3.161 +features include trust management, via digital signatures, and free-form 
   3.162 +extensibility via RDFa. By using the existing SSL certificate exchange
   3.163 +mechanism, WebID integrates more smoothly with existing Web browsers, including
   3.164 +browsers on mobile devices. WebID also permits automated session login
   3.165 +in addition to interactive session login. Additionally, all data is encrypted
   3.166 +and guaranteed to only be received by the person or organization that was 
   3.167 +intended to receive it.
   3.168 +</p>
   3.169 +
   3.170 +</div>
   3.171 +
   3.172 +<div class="informative section" id="relation-to-openid" typeof="bibo:Chapter" about="#relation-to-openid">
   3.173 +<h3><span class="secno">1.2 </span>Relation to OpenID</h3><p><em>This section is non-normative.</em></p>
   3.174 +
   3.175 +<p>While some may say that OpenID and WebID conflict, WebID is 100% compatible
   3.176 +with OpenID since both use a URL for identification. Therefore, WebID does not
   3.177 +intend to replace OpenID, but can work beside OpenID just as easily as providing
   3.178 +a complete solution. That said, there are a number of benefits that WebID
   3.179 +achieves over OpenID:
   3.180 +</p>
   3.181 +
   3.182 +<p>WebID gives people and other agents a Web ID URL for identification, just
   3.183 +like OpenId does. However, in the case of WebID, the user does not need to
   3.184 +remember the URL, the browser or User Agent does. A login button on a
   3.185 +WebID web site is just a button. No need to enter any identifier like one
   3.186 +has to for OpenID. Just click the button. Your browser will then ask you what 
   3.187 +identity you wish to use. The person that is browsing does not need to 
   3.188 +remember either the WebID URL or the website password. The only password one
   3.189 +needs to remember is the one that is used to access their collection of
   3.190 +WebIDs in their browser.</p>
   3.191 +
   3.192 +<p>The WebID protocol requires just one direct network connection to establish
   3.193 +identity via the client. The server requires one connection to the client and
   3.194 +one connection to retrieve the WebID URL if it does not have the credential
   3.195 +information cached. Compare this to the much more complex OpenID sequence, which
   3.196 +requires six connections by the client to establish a login. In a world of 
   3.197 +distributed data where each site can point to data on any other site, multiple 
   3.198 +connections become costly to manage.</p>
   3.199 +
   3.200 +<p>WebID builds on well established Internet and Web standards;
   3.201 +<a href="http://en.wikipedia.org/wiki/REST">REST</a>, 
   3.202 +RDF [<a class="bibref" rel="biblioentry" href="#bib-RDF-PRIMER">RDF-PRIMER</a>], RDFa [<a class="bibref" rel="biblioentry" href="#bib-RDFA-CORE">RDFA-CORE</a>], TLS [<a class="bibref" rel="biblioentry" href="#bib-HTTP-TLS">HTTP-TLS</a>], and X.509 
   3.203 +[<a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a>]. By building on previous standards, it makes both explaining and 
   3.204 +implementing WebID easier on developers.</p>
   3.205 +
   3.206 +<p>Since WebID is RESTful, you can perform basic HTTP operations to 
   3.207 +<code>GET</code> your WebID, and if you needed update it, you can use
   3.208 +HTTP <code>PUT</code> semantics. You can also create a WebID via 
   3.209 +<code>POST</code>. This is improved from the OpenID specification, which
   3.210 +requires a new set of operations described in the OpenID Attribute Exchange
   3.211 +specification.</p>
   3.212 +
   3.213 +<p>It is easy to extend a WebID with new attributes via RDF. The power of
   3.214 +RDF and RDFa allows developers to add extensions to WebID by defining new
   3.215 +vocabularies that they publish. There is no authorization process necessary
   3.216 +and thus WebID allows for distributed innovation. Every WebID property is
   3.217 +a URI, which when clicked, can give you yet more information about what the
   3.218 +property means. A developer can create new usage classes by extending their
   3.219 +vocabulary at will. A developer can add relationships to a WebID by simply
   3.220 +adding more HTML to the developer's page. OpenID does not provide any type of
   3.221 +distributed innovation akin to RDF or RDFa.</p>
   3.222 +
   3.223 +<p>WebID is built on RDF and thus enables all of the advanced semantic web
   3.224 +concepts that RDF enables. For example, a developer may perform machine
   3.225 +reasoning with a WebID. One can construct machine-executable statements like
   3.226 +"If this WebID claims to be a friend of one of our partner WebIDs that is
   3.227 +trusted and the relationship is bi-directional, trust the WebID." 
   3.228 +While OpenID attempts to support this use case by mapping OpenID to RDF, it's
   3.229 +far easier to do with WebID because WebID is natively RDF-aware.</p>
   3.230 +
   3.231 +<p>Implementing WebID is easier than OpenID because all of the basic 
   3.232 +technologies have been working and integrated into Web browsers for many years. 
   3.233 +There were already three interoperable implementations of WebID before this 
   3.234 +specification was written.</p>
   3.235 +
   3.236 +<p>WebID is truly decentralized - with WebID you get a web of trust. 
   3.237 +OpenID only supports the Web of Trust model if you indirectly trust the
   3.238 +OpenID provider. In other words - OpenID is not truly decentralized. In OpenID
   3.239 +you must trust OpenID providers. With WebID you only have to trust the people
   3.240 +and the organizations with which you are communicating. In other words, you
   3.241 +don't have to ask anyone whether or not you can trust your friends. You can
   3.242 +query people that you trust directly to see if someone is trustworthy or not.
   3.243 +There is no need for a central WebID authority.
   3.244 +</p>
   3.245 +
   3.246 +<p>WebID is fully distributed, anyone can setup a WebID by placing a single
   3.247 +file on a web server of their choosing. There is no need for a special 
   3.248 +OpenID-like provider service. The only thing anyone that wants a WebID needs
   3.249 +is a web account where you can post your WebID file, ideally on your own domain 
   3.250 +name. You can also use a WebID hosting provider, but it's not necessary for
   3.251 +WebID to work. While it is possible to run an OpenID server, other
   3.252 +OpenID applications may not trust you and thus you won't be able to fully
   3.253 +utilize your private OpenID credentials. The reason that there are a few
   3.254 +large OpenID providers and very few small OpenID providers is because of this
   3.255 +trust design issue related to OpenID.</p>
   3.256 +
   3.257 +<p>WebID does not require HTTP redirects. Redirects are are problematic on many
   3.258 +cell phones, because telecoms heavily rely on proxys, which selectively block
   3.259 +redirects.</p>
   3.260 +
   3.261 +<p>A WebID provider is 100% compatible with an OpenID provider and thus can 
   3.262 +inter-operate with OpenID-powered networks.</p>
   3.263 +
   3.264 +</div>
   3.265 +
   3.266 +<div class="informative section" id="relation-to-oauth" typeof="bibo:Chapter" about="#relation-to-oauth">
   3.267 +<h3><span class="secno">1.3 </span>Relation to OAuth</h3><p><em>This section is non-normative.</em></p>
   3.268 +
   3.269 +<p>
   3.270 +OAuth and WebID are mutually beneficial when used together. WebID can be
   3.271 +used to provide RSA parameters to the RSA-SHA1 signature method required by
   3.272 +OAuth 1.0. WebID can also be used to establish the consumer_key and HTTPS 
   3.273 +connection that will be used to transmit OAuth Tokens in OAuth 2.0.
   3.274 +</p>
   3.275 +
   3.276 +</div>
   3.277 +</div>
   3.278 +
   3.279 +<div class="normative section" id="the-webid-protocol" typeof="bibo:Chapter" about="#the-webid-protocol">
   3.280 +
   3.281 +<!-- OddPage -->
   3.282 +<h2><span class="secno">2. </span>The WebID Protocol</h2>
   3.283 +
   3.284 +<div class="normative section" id="terminology" typeof="bibo:Chapter" about="#terminology">
   3.285 +<h3><span class="secno">2.1 </span>Terminology</h3>
   3.286 +
   3.287 +<dl>
   3.288 +<dt><dfn title="Verification_Agent" id="dfn-verification_agent">Verification Agent</dfn></dt>
   3.289 +<dd>Performs authentication on provided WebID credentials and determines if
   3.290 +an <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a> can have access to a particular 
   3.291 +resource. A <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> is typically a Web server, but 
   3.292 +may also be a peer on a peer-to-peer network.</dd>
   3.293 +<dt><dfn title="Identification_Agent" id="dfn-identification_agent">Identification Agent</dfn></dt>
   3.294 +<dd>Provides identification credentials to a Verification Agent. The
   3.295 +<a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a> is typically also a User Agent.</dd>
   3.296 +<dt><dfn title="Identification_Certificate" id="dfn-identification_certificate">Identification Certificate</dfn></dt>
   3.297 +<dd>An X.509 [<a class="bibref" rel="biblioentry" href="#bib-X509V3">X509V3</a>] Certificate that <em class="rfc2119" title="must">must</em> contain the 
   3.298 +<code>Subject Alternative Name</code> field pointing to a URL that is
   3.299 +dereference-able and results in an [<a class="bibref" rel="biblioentry" href="#bib-XHTML-RDFA">XHTML-RDFA</a>] document. For example 
   3.300 +the certificate would contain <code>http://example.org/webid#public</code> as
   3.301 +the <code>Subject Alternative Name</code>:
   3.302 +<code><pre>
   3.303 +X509v3 extensions:
   3.304 +   ...
   3.305 +   X509v3 Subject Alternative Name:
   3.306 +      URI:http://example.org/webid#public
   3.307 +</pre></code>
   3.308 +</dd><dt><dfn title="WebID_URL" id="dfn-webid_url">WebID URL</dfn></dt>
   3.309 +<dd>The URL that contains identification credentials for the 
   3.310 +<a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a> encoded in RDFa [<a class="bibref" rel="biblioentry" href="#bib-XHTML-RDFA">XHTML-RDFA</a>].</dd>
   3.311 +
   3.312 +</dl>
   3.313 +
   3.314 +</div>
   3.315 +
   3.316 +<div class="normative section" id="authentication-sequence" typeof="bibo:Chapter" about="#authentication-sequence">
   3.317 +<h3><span class="secno">2.2 </span>Authentication Sequence</h3>
   3.318 +
   3.319 +<p>The following steps are executed by Verification Agents and Identification
   3.320 +Agents to determine if access should be granted to a particular resource.
   3.321 +</p>
   3.322 +
   3.323 +<ol>
   3.324 +<li>The <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a> attempts to access a resource
   3.325 +using HTTP over TLS [<a class="bibref" rel="biblioentry" href="#bib-HTTP-TLS">HTTP-TLS</a>] via the <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a>.</li>
   3.326 +
   3.327 +<li>The <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> <em class="rfc2119" title="must">must</em> request the 
   3.328 +<a class="tref internalDFN" title="Identification_Certificate" href="#dfn-identification_certificate">Identification Certificate</a> of the <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a>
   3.329 +as a part of the TLS client-cerificate retrieval protocol.</li>
   3.330 +
   3.331 +<li>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="WebID_URL" href="#dfn-webid_url">WebID URL</a> 
   3.332 +contained in the <code>Subject Alternative Name</code> field of the 
   3.333 +<a class="tref internalDFN" title="Identification_Certificate" href="#dfn-identification_certificate">Identification Certificate</a>. The <a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a> <em class="rfc2119" title="must">must</em> be 
   3.334 +dereferenced and the resulting document processed according to [<a class="bibref" rel="biblioentry" href="#bib-XHTML-RDFA">XHTML-RDFA</a>]. 
   3.335 +All triples pertaining to the public key associated with the 
   3.336 +<a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a> <em class="rfc2119" title="must">must</em> be extracted from the remote document.</li>
   3.337 +
   3.338 +<li>The remote document triples <em class="rfc2119" title="must">must</em> be queried for information about the 
   3.339 +public key contained in the <a class="tref internalDFN" title="Identification_Certificate" href="#dfn-identification_certificate">Identification Certificate</a>. 
   3.340 +If the public key in the certificate is found in the list of public keys 
   3.341 +associated with the <a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a>, the <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a>
   3.342 +<em class="rfc2119" title="must">must</em> assume that the client has write access to the <a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a> and
   3.343 +therefore owns the URL.</li>
   3.344 +
   3.345 +<li>At this point, the <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> has verified that the
   3.346 +<a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a> is owned by the <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a>. The
   3.347 +<a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> <em class="rfc2119" title="must">must</em> use the now verified public key contained 
   3.348 +in the <a class="tref internalDFN" title="Identification_Certificate" href="#dfn-identification_certificate">Identification Certificate</a> for all TLS-based communication
   3.349 +with the <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a>.
   3.350 +</li></ol>
   3.351 +
   3.352 +<p>
   3.353 +The <a class="tref internalDFN" title="Identification_Agent" href="#dfn-identification_agent">Identification Agent</a> <em class="rfc2119" title="may">may</em> re-establish a different identity at 
   3.354 +any time by executing all of the steps in the Authentication Sequence again. 
   3.355 +Additional algorithms, detailed in the next section, <em class="rfc2119" title="may">may</em> be performed to 
   3.356 +determine if the <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> can access a particular 
   3.357 +resource after the last step of the Authentication Sequence has been
   3.358 +completed.
   3.359 +</p>
   3.360 +
   3.361 +</div>
   3.362 +
   3.363 +<div class="normative section" id="authentication-sequence-details" typeof="bibo:Chapter" about="#authentication-sequence-details">
   3.364 +<h3><span class="secno">2.3 </span>Authentication Sequence Details</h3>
   3.365 +
   3.366 +<p>This section covers details about each step in the authentication process.
   3.367 +</p>
   3.368 +
   3.369 +<div class="normative section" id="initiating-a-tls-connection" typeof="bibo:Chapter" about="#initiating-a-tls-connection">
   3.370 +<h4><span class="secno">2.3.1 </span>Initiating a TLS Connection</h4>
   3.371 +
   3.372 +<p class="issue">This section will detail how the TLS connection process is
   3.373 +started and used by WebID to create a secure channel between the 
   3.374 +Identification Agent and the Verification Agent.</p>
   3.375 +</div>
   3.376 +
   3.377 +<div class="normative section" id="exchanging-the-identification-certificate" typeof="bibo:Chapter" about="#exchanging-the-identification-certificate">
   3.378 +<h4><span class="secno">2.3.2 </span>Exchanging the Identification Certificate</h4>
   3.379 +
   3.380 +<p class="issue">This section will detail how the certificate is selected and
   3.381 +sent to the Verification Agent.</p>
   3.382 +</div>
   3.383 +
   3.384 +<div class="normative section" id="processing-the-webid-url" typeof="bibo:Chapter" about="#processing-the-webid-url">
   3.385 +<h4><span class="secno">2.3.3 </span>Processing the WebID URL</h4>
   3.386 +
   3.387 +<p class="issue">This section will explain how a Verification Agent extracts 
   3.388 +semantic data describing the identification credentials from a WebID URL.</p>
   3.389 +</div>
   3.390 +
   3.391 +<div class="normative section" id="extracting-identification-url-details" typeof="bibo:Chapter" about="#extracting-identification-url-details">
   3.392 +<h4><span class="secno">2.3.4 </span>Extracting Identification URL Details</h4>
   3.393 +
   3.394 +<p>
   3.395 +The <a class="tref internalDFN" title="Verification_Agent" href="#dfn-verification_agent">Verification Agent</a> may use a number of different methods to
   3.396 +extract the public key information from the <a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a>.
   3.397 +</p>
   3.398 +The following SPARQL query outlines one way in which the public key
   3.399 +could be extracted from the <a class="tref internalDFN" title="WebID_URL" href="#dfn-webid_url">WebID URL</a>:
   3.400 +<code><pre>
   3.401 +PREFIX cert: &lt;http://www.w3.org/ns/auth/cert#&gt;
   3.402 +PREFIX rsa: &lt;http://www.w3.org/ns/auth/rsa#&gt;
   3.403 +SELECT ?modulus ?exp
   3.404 +WHERE {
   3.405 +   ?key cert:identity &lt;http://example.org/webid#public&gt;;
   3.406 +      a rsa:RSAPublicKey;
   3.407 +      rsa:modulus [ cert:hex ?modulus; ];
   3.408 +      rsa:public_exponent [ cert:decimal ?exp ] .
   3.409 +}
   3.410 +</pre></code>
   3.411 +
   3.412 +<p class="issue">This section still needs more information.</p>
   3.413 +
   3.414 +</div>
   3.415 +
   3.416 +<div class="normative section" id="determining-access-privileges" typeof="bibo:Chapter" about="#determining-access-privileges">
   3.417 +<h4><span class="secno">2.3.5 </span>Determining Access Privileges</h4>
   3.418 +
   3.419 +<p class="issue">This section will explain how a Verification Agent may
   3.420 +use the information discovered via a WebID URL to determine if one should
   3.421 +be able to access a particular resource. It will explain how a Verification
   3.422 +Agent can use links to other RDFa documents to build knowledge about the
   3.423 +given WebID.</p>
   3.424 +
   3.425 +</div>
   3.426 +
   3.427 +</div>
   3.428 +
   3.429 +<div id="appendix" typeof="bibo:Chapter" about="#appendix" class="section">
   3.430 +
   3.431 +<div class="informative section" id="history" typeof="bibo:Chapter" about="#history">
   3.432 +<h4>Change History</h4><p><em>This section is non-normative.</em></p>
   3.433 +<p>2010-07-11 Initial version.</p>
   3.434 +</div>
   3.435 +
   3.436 +<div class="informative section" id="acknowledgements" typeof="bibo:Chapter" about="#acknowledgements">
   3.437 +<h4>Acknowledgments</h4><p><em>This section is non-normative.</em></p>
   3.438 +
   3.439 +<p>The following people have been instrumental in providing thoughts, feedback,
   3.440 +reviews, criticism and input in the creation of this specification:</p>
   3.441 +
   3.442 +<ul>
   3.443 +<li>Melvin Carvalho</li>
   3.444 +<li>Bruno Harbulot</li>
   3.445 +<li>Toby Inkster</li>
   3.446 +<li>Ian Jacobi</li>
   3.447 +<li>Jeff Sayre</li>
   3.448 +<li>Henry Story</li>
   3.449 +</ul>
   3.450 +
   3.451 +</div>
   3.452 +</div>
   3.453 +  
   3.454 +
   3.455 +
   3.456 +</div><div id="references" class="appendix section" typeof="bibo:Chapter" about="#references">
   3.457 +<!-- OddPage -->
   3.458 +<h2><span class="secno">A. </span>References</h2><div id="normative-references" typeof="bibo:Chapter" about="#normative-references" class="section"><h3><span class="secno">A.1 </span>Normative references</h3><dl class="bibliography" about=""><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> 
   3.459 +</dd><dt id="bib-RDFA-CORE">[RDFA-CORE]</dt><dd rel="dcterms:requires">Shane McCarron; et al. <a href="http://www.w3.org/TR/2010/WD-rdfa-core-20100422"><cite>RDFa Core 1.1: Syntax and processing rules for embedding RDF through attributes.</cite></a>22 April 2010. W3C Working Draft. URL: <a href="http://www.w3.org/TR/2010/WD-rdfa-core-20100422">http://www.w3.org/TR/2010/WD-rdfa-core-20100422</a> 
   3.460 +</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>.
   3.461 +</dd><dt id="bib-XHTML-RDFA">[XHTML-RDFA]</dt><dd rel="dcterms:requires">Shane McCarron; et. al. <a href="http://www.w3.org/TR/2010/WD-xhtml-rdfa-20100422"><cite>XHTML+RDFa 1.1.</cite></a> 22 April 2010. W3C Working Draft. URL: <a href="http://www.w3.org/TR/2010/WD-xhtml-rdfa-20100422">http://www.w3.org/TR/WD-xhtml-rdfa-20100422</a> 
   3.462 +</dd></dl></div><div id="informative-references" typeof="bibo:Chapter" about="#informative-references" class="section"><h3><span class="secno">A.2 </span>Informative references</h3><dl class="bibliography" about=""><dt id="bib-RDF-PRIMER">[RDF-PRIMER]</dt><dd rel="dcterms:references">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> 
   3.463 +</dd></dl></div></div></body></html>