--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/card.rdf Mon Jun 13 18:58:43 2011 +0200
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="utf-8" ?>
+
+<rdf:RDF
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:foaf="http://xmlns.com/foaf/0.1/">
+
+ <foaf:PersonalProfileDocument rdf:about="http://fcns.eu/group/webid/info.rdf">
+ <foaf:maker rdf:resource="http://fcns.eu/people/andrei/card#me"/>
+ <foaf:primaryTopic rdf:resource="#webIDXG"/>
+ </foaf:PersonalProfileDocument>
+
+ <!-- WebID -->
+ <foaf:Group rdf:ID="webIDXG">
+ <foaf:name>The WebID Incubator Group</foaf:name>
+ <foaf:homepage rdf:resource="http://www.w3.org/2005/Incubator/webid/"/>
+
+ <!-- Members list -->
+ <foaf:member rdf:resource="http://bblfish.net/people/henry/card#me"/>
+ <foaf:member rdf:resource="http://fcns.eu/people/andrei/card#me"/>
+ <foaf:member rdf:resource="http://kingsley.idehen.net/dataspace/person/kidehen#this"/>
+ <foaf:member rdf:resource="http://melvincarvalho.com/#me"/>
+ <foaf:member rdf:resource="http://www.bergnet.org/people/bergi/card#me"/>
+ <foaf:member rdf:resource="http://openspring.net/scor#me"/>
+ </foaf:Group>
+</rdf:RDF>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/papers/identity-ws-2011/webid.html Mon Jun 13 18:58:43 2011 +0200
@@ -0,0 +1,312 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
+ "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:foaf="http://xmlns.com/foaf/0.1/" version="XHTML+RDFa 1.0" xml:lang="en">
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <meta property="dc:subject" content="identity, WebID, authentication, Browser, REST, HTTPS, Public-key cryptography" />
+ <title>The WebID Protocol & Browsers</title>
+ <style type="text/css">
+ @import url("http://www.w3.org/StyleSheets/TR/base.css");
+ body {
+ font-family: Arial, Helvetica, sans-serif;
+ width: 80%;
+ background-color: white;
+ text-align: justify;
+ }
+ h1, div.description, div.figure {
+ text-align:center;
+ }
+ pre {
+ background-color: #FFFFE0;
+ }
+ .headerish { color: #005A9C; background: white }
+ .highlight {
+ color:red;
+ font-weight:bold;
+ }
+ ul.authorship { list-style:none; }
+ ul.authorship li { display: inline; }
+ ul.authorship li:after { content: ' • ' }
+ </style>
+</head>
+
+<body>
+ <h1 property="dc:title">The WebID Protocol & Browsers</h1>
+ <div class="description">
+ <p datatype="" property="dc:description">Position Paper for <a href=
+ "http://www.w3.org/2011/identity-ws/">W3C Workshop on Identity in the Browser</a>
+ 24/25th May 2011, Mountain View (USA)</p>
+
+ <p>Presented by members of the <a href=
+ "http://www.w3.org/2005/Incubator/webid/">
+ W3C WebID Incubator Group</a></p>
+
+
+ <p class="headerish"><strong>Authors</strong>:</p>
+ <ul class="authorship" rel="dc:creator">
+ <li typeof="foaf:Person">• <a rel="foaf:homepage" href="http://jeffsayre.com/" property="foaf:name">Jeff Sayre</a></li>
+ <li about="http://bblfish.net/#hjs" typeof="foaf:Person"><a rel="foaf:homepage" href="http://bblfish.net/" property="foaf:name">Henry Story</a>, WebID Incubator Chair</li>
+ </ul>
+
+ <p class="headerish"><strong>Contributors</strong>:</p>
+ <ul class="authorship" rel="dc:contributor"><li typeof="foaf:Person">•
+ <a rel="foaf:workInfoHomepage" href="http://www.cs.kent.ac.uk/people/staff/dwc8/" property="foaf:name">David Chadwick</a>, University of Kent</li>
+ <li about="http://openspring.net/scor#me" typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" href="http://openspring.net/scor">Stéphane Corlosquet</a></li>
+ <li typeof="foaf:Person"><a rel="foaf:workInfoHomepage" property="foaf:name" href="http://vsr.informatik.tu-chemnitz.de/people/gaedke/">Martin Gaedke</a>, Chemnitz University of Technology</li>
+ <li typeof="foaf:Person"><a rel="foaf:blog" property="foaf:name" href="http://www.openlinksw.com/blog/~kidehen/">Kingsley Idehen</a>, OpenLink Software</li>
+ <li typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" href="http://apassant.net/alex">Alexandre Passant</a>, DERI, NUI Galway</li>
+ <li about="http://fcns.eu/people/andrei/card#me" typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" href="http://fcns.eu/">Andrei Sambra</a></li>
+ <li typeof="foaf:Person"><a rel="foaf:workInfoHomepage" href="http://ii.uwb.edu.pl/~dtomaszuk/" property="foaf:name">Dominik Tomaszuk</a>, <a rel="foaf:workplaceHomepage" href="http://ii.uwb.edu.pl/">University of Bialystok</a></li>
+ <li typeof="foaf:Person"><a rel="foaf:made" property="foaf:name" href="http://portal.acm.org/citation.cfm?id=560938">Peter Williams</a></li>
+ </ul>
+ </div>
+
+ <h2>1. Position Statement</h2>
+
+
+ <p>The browser is both the interface to the
+ Web as well as presenting the user's face to the world. The browser user should
+ therefore be conscious of the face he is presenting at any time. He should be able to
+ change it easily: identity selection should be a one-click gesture,
+ cryptographically-secure, and web site independent. It should put the user in control
+ of the information he shares with each site. And it should be available
+ now.</p>
+
+
+ <p>The WebID protocol enables all of the
+ above. It works in all browsers that correctly implement HTTPS and client-side
+ certificates. But with a twist: it ties those certificates into the web in a
+ <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">RESTful manner</a> allowing identities to be linked together in
+ a secure social web of trust, that does not require central authorities, and that
+ allows the user to control how he describes himself to each site he logs
+ into.</p>
+
+
+ <p>After describing the WebID protocol and its benefits, we will suggest a roadmap for future improvements in the browser that can take advantage of it.</p>
+
+
+ <h2>2. WebID Overview</h2>
+
+ <p>To illustrate how WebID works, we will first look in detail at what happens on the wire when Bob connects for the first time to a protected resource on Alice's Web Server. This resource could simply be a login button, or it could be any of the resources published there. This should help show just how simple and efficient the protocol is: it requires only one more HTTP connection than the original resource
+ requested, and the results of this connection can be cached. </p>
+
+ <ol>
+ <li>Bob requests
+ Alice's protected HTTPS resource</li>
+ <li>Alice's web
+ server requests the client certificate on the TLS connection started above</li>
+ <li>Bob's browser
+ presents him with a selection of identities to choose from: <div class="figure"><img width=
+ "576" height="235" src="webid_images/image001.jpg" alt="" /></div>Having selected one, the corresponding X509
+ certificate is sent to Alice's server:
+ <pre> Public Key Info:
+ Public Key Algorithm: rsaEncryption
+ Public-Key: (1024 bit)
+ Modulus:
+ 00:e8:f9: [snip] :c6:af:2e
+ Exponent: 65537 (0x10001)
+ X509v3 extensions:
+ X509v3 Subject Alternative Name:
+ URI: <span class="highlight">https://bob.net/id/bob#me</span></pre>
+ It contains Bob's WebID, shown in bold red above.</li>
+ <li>Alice's server:<ol>
+ <li>checks that
+ Bob's browser is in possession of the private key corresponding to the public key
+ sent in the certificate, as specified by TLS</li>
+ <li>extracts the
+ URI from the Subject Alternative Name field of the certificate, which is known as
+ Bob's WebID: a global identifier that refers to Bob via a document that describes
+ him, in a machine readable way using W3C standards.<div class="figure"><img width="708" height="544" src=
+ "webid_images/WebIDSequence-friendly.jpg" alt="" /></div></li>
+ </ol></li>
+ <li>Alice's server
+ fetches Bob's WebID Profile at https://bob.net/id/bob in the example if an up to date
+ version is not in the cache</li>
+ <li>Alice's server
+ checks that the profile relates Bob's WebID to the public key found in the
+ certificate. If they match then she knows that she is in
+ communication with the agent referred to by https://bob.net/id/bob#me</li>
+ <li>Bob's identity
+ is then checked as to its position in a graph of relations in order to determine
+ trust according to some criteria decided by Alice combined with information from the
+ cloud.<br/>
+ This is outside the core of WebID, but it is important to
+ understand how it can work. Alice might decide for example that only a group of
+ friends who have given her a WebID personally may have access. Or she may be more
+ lenient, and allow any of the <a href="http://xmlns.com/foaf/0.1/">friends of those friends</a> to also access that
+ resource, as specified by them in their profile located on their servers. Or she may
+ only trust employees of her company, or of her department, to view that resource.
+ Alice's server can do a lookup in a local file, crawl the web at intervals, or use
+ web services to gather the data to help make that decision.</li>
+ <li>Access is
+ granted fully, partially, or denied and a representation is returned. Assuming the
+ resource requested is a friend graph, a full representation could be returned to a
+ friend, and a very limited one to an anonymous user.</li>
+ </ol>
+
+ <p>The WebID placed in the X509 Certificate can be a https URL as
+ shown above. Although the HTTPS scheme is currently the most widely implemented,
+ WebID could also used with any dereferenceable scheme such as ftps://, ldaps://,
+ xris://, accnt: (used by <a href="http://code.google.com/p/webfinger/">webfinger</a> ). It could also be used in future schemes such as
+ <a href="http://lists.w3.org/Archives/Public/public-xg-webid/2011Mar/0068.html">
+ httpk</a> that would give up human readable URIs in order to
+ avoid the centralisation problems of DNS.</p>
+
+
+ <h2>3. Advantages of WebID</h2>
+
+
+ <p>Issues of identity and privacy have been
+ growing increasingly serious as the Web has become social over the last decade.
+ Remembering login details has grown into a serious security issue as more sites asked
+ for them than people had the ability to remember. And the inability to easily share
+ restricted information across websites has become a visible problem to 100s of
+ millions of people as they started finding themselves and those they wished to
+ communicate with split across siloed services.</p>
+
+ <p>Specifically, WebID offers the following
+ advantages.</p>
+
+
+ <h3>3.1 Overcoming Password Fatigue</h3>
+
+
+ <p>Passwords are <em>difficult</em> to remember or
+ they are easy to crack. As a result people tend to re-use them, making phishing
+ attacks the biggest threat on the web, leading to a mistrust of new services. WebID
+ uses TLS-client certificates and public key cryptography as shipped in current
+ browsers in a way that enables the same certificate to be used across sites securely.
+ Furthermore with the HTML5 supported <code>keygen</code> element, creating such a certificate is
+ as easy as submitting an HTML form.</p>
+
+
+ <h3>3.2 OpenID</h3>
+
+
+ <p><a href="http://openid.net/">OpenID</a>
+ reduces the account multiplication issue by allowing users to login
+ to every site using the same global identifier. This provides a base from which WebId can be deployed,
+ procuring the following extra advantages:</p>
+
+ <ul>
+ <li><strong>Protocol
+ simplicity</strong>: the WebID protocol is a lot simpler,
+ requiring only one more connection over and above the connection to the requested
+ resource, where the result is cacheable. OpenID <a href=
+ "http://blogs.sun.com/bblfish/entry/the_openid_sequence_diagram">requires seven TLS connections</a>, significantly more than WebID. These
+ additional steps create opportunities for denial of service attacks, making it more
+ difficult to secure and to debug.</li>
+ <li><strong>User-interaction
+ simplicity</strong>: OpenID requires the user to remember and type
+ an OpenID URL. WebID hides this in the X509 certificate allowing the browser to offer
+ select-and-click interaction. This is very helpful anywhere, but especially on
+ <a href="http://blogs.sun.com/bblfish/entry/one_click_global_sign_on">handheld devices</a>.</li>
+ </ul>
+
+<p>These protocol simplifications create a cascade of additional benefits. WebID can be applied recursively, enabling the Relying Party (Alice above) to identify herself using WebID, making it easy to <a href="http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo">build an authorisation protocol</a>. WebId takes full advantage of the peer to peer nature of the Web. </p>
+
+ <h3>3.3 Public Key Infrastructure</h3>
+
+
+ <p>TLS-client certificates have been available in
+ the browser since 1996, but their usage has been limited to a small number of sites.
+ The organisation which generates the certificate is usually the same as the one that
+ consumes it, giving the user little advantage over username/passwords layered on
+ server-side https. Outside of very large and well-funded Defence related
+ organisations, client-side certificates have thus had very poor adoption.</p>
+
+ <p>The missing link to wide adoption is the global naming system
+ that OpenID takes advantage of with URLs, and that allows one to potentially
+ authenticate to all sites. What failed TLS was that X500 names were not Universal
+ Identifiers, were not designed to form an interlinked web, and hence were not usable
+ to authenticate to sites without those first having a federated agreement. One can easily
+ imagine how much resistance there would have been to global hypertext system if organisations had
+ to first make an agreement with every web site they wanted to visit, before their users
+ were able to visit them. </p>
+
+ <p>Having solved the naming/identity problem using standard URLs, WebId authorization agents can then use the web of interlinked profiles and other resources (eg. academic publications, ...) to calculate trust in a dynamic manner. Since trust can then be spread to a much large network of actors, each bringing a small piece of information to the graph, this allows both greater resilience in the system and more flexibility.</p>
+
+
+ <h3>3.4 Future Proof Protocol</h3>
+
+ <p>Not only does WebID work with the Web as it is
+ today, but it will be strengthened with the rollout of critical infrastructure
+ elements such as DNSSEC, which can be used as <a href=
+ "http://www.wired.com/techbiz/people/magazine/16-12/ff_kaminsky?currentPage=all">Dan Kaminsky</a>
+ explains in his <a href="http://dankaminsky.com/2010/12/13/dnssec-ch1/">DNSSEC Diaries</a>
+ to publish public keys of services, a work being developed formally
+ by the <a href=
+ "http://datatracker.ietf.org/wg/dane/charter/">
+ IETF Dane</a>
+ working group. This can be used to increase trust in all server
+ certificates, but in particular self-signed server certificates, which according to a
+ report by the <a href=
+ "http://www.eff.org/observatory">
+ EFF Observatory</a>
+ are three times more numerous than CA-signed certificates. By
+ lowering the entry barrier to using cryptography, both WebID and Dane will help bring
+ about an increasingly-secure Web.</p>
+
+ <h2>4. Recommended Browser Improvements</h2>
+
+ <p>All current browser-based authentication
+ methods fail to give full control over identity to the user. We declare that browsers
+ MUST give the user full visible control of their identity. With TLS, as with cookies,
+ one should be able to see clearly which identity one is logged in under and be able
+ to easily become anonymous again, as far as that is possible of course. The Firefox
+ Weave team have shown what this could look like, making use of the URL bar's existing
+ role as guarantor of server identity and extending it to client identity.</p>
+
+ <div class="figure"><img width="278" height="157" src=
+ "webid_images/image003.jpg" alt="" /><img width="337" height="202" src=
+ "webid_images/image004.jpg" alt="" /></div>
+
+ <p>Here the user can see what persona they are
+ presenting to the site or if they are anonymous. It also permits the user to change
+ identity or to log out. The browser could then make use of the information found in
+ the WebID profile--linked to from the X509 certificate--such as finding a link to a
+ picture which could then be displayed, or linking to the account management page as
+ shown above.</p>
+
+ <p>This WebID anchor can then be used by browsers
+ to improve the user experience by:</p>
+ <ul>
+ <li>using bookmarking
+ services linked to from the profile</li>
+ <li>using the linked social
+ graph to provide real time changes to address books as well as social web based spam
+ protection</li>
+ <li>building micropayment
+ services by using the TLS cryptography layer, ...</li>
+ </ul>
+
+ <h2>5. Conclusion</h2>
+
+ <p>WebID allows users to authenticate easily and
+ securely to any website in the world in a one click gesture without needing to fill
+ out any new forms. That site can immediately personalise the experience given the
+ information and social graph made available to it by the user (see <a href="http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo">Sketch of a RESTful photo Printing service</a> ). This will allow innumerable applications
+ to be built that improve relations between individuals and their friends, co-workers,
+ employers, and vendors across domain and organisational boundaries.</p>
+
+ <p>The <a href="http://www.w3.org/2005/Incubator/webid/">
+ W3C WebID Incubator Group</a>
+ is keen to work with browser vendors and Web service providers to
+ help standardise the necessary formats, semantics, and RESTful protocols and to provide test suites for these. We are also keen to work with the <a href="http://www.w3.org/2005/Incubator/federatedsocialweb/">Federated Social Web XG</a> to build interoperable services in order to discover what gets adopted, standardise those pieces that are most widely agreed on, and discover issues that require longer term research to be resolved.</p>
+
+ <h2>6. Additional Resources</h2>
+ <ul>
+ <li><a href=
+ "http://www.w3.org/2005/Incubator/webid/spec/">
+ WebID Draft Spec</a></li>
+ <li><a href=
+ "http://www.w3.org/wiki/Foaf%2Bssl/FAQ">
+ WebID Frequently Asked Questions</a></li>
+ <li><a href=
+ "http://www.w3.org/wiki/Foaf%2Bssl">WebID Wiki</a></li>
+ </ul>
+
+
+</body>
+</html>
Binary file papers/identity-ws-2011/webid_images/WebIDSequence-friendly.graffle has changed
Binary file papers/identity-ws-2011/webid_images/WebIDSequence-friendly.jpg has changed
Binary file papers/identity-ws-2011/webid_images/image001.jpg has changed
Binary file papers/identity-ws-2011/webid_images/image003.jpg has changed
Binary file papers/identity-ws-2011/webid_images/image004.jpg has changed
--- a/spec/README Mon Jun 13 18:54:10 2011 +0200
+++ b/spec/README Mon Jun 13 18:58:43 2011 +0200
@@ -3,57 +3,70 @@
WebID 1.0
Web Identification and Discovery
-Identification and privacy have been at the center of how we interact
-with sites on the Web. The explosion of Websites over the last decade
-and a half has created a point of pain for anyone that uses the Web on a
-regular basis. Remembering login details, passwords, and sharing private
-information across the many websites that people use on a daily basis
-has become more difficult and complicated than necessary. This
-specification outlines a simple universal identification mechanism that
-is distributed, openly extensible, improves privacy, security and
-control over how one can identify themselves and control access to their
-information on the Web.
+Identification and privacy have been at the center of how we interact with sites
+on the Web. The explosion of Websites over the last decade and a half has
+created a point of pain for anyone that uses the Web on a regular basis.
+Remembering login details, passwords, and sharing private information across the
+many websites that people use on a daily basis has become more difficult and
+complicated than necessary. This specification outlines a simple universal
+identification mechanism that is distributed, openly extensible, improves
+privacy, security and control over how one can identify themselves and control
+access to their information on the Web.
Source
------
-You can read, branch and modify the source code for this specification via
-github:
+You can read, branch and modify the source code for this specification via the
+main WebID hg repository hosted by the W3C:
-https://github.com/webid-community/webid-spec
+https://dvcs.w3.org/hg/WebID
+
+For those more familiar with git, a secondary repository is kept in sync on
+github: https://github.com/webid-community/webid-spec
Feedback
--------
-Don't e-mail patches to the editors, don't send tweets, IMs, or e-mails.
-Log bugs if you want to request changes to the spec, it is the only way
-you can make sure that your input will be tracked and considered by
-the group:
+Send an email to the WebID XG public mailing list if you want to request changes
+to the spec, it is the only way you can make sure that your input will be
+tracked and considered by the group:
-https://github.com/webid-community/webid-spec/issues
+http://lists.w3.org/Archives/Public/public-xg-webid/
-When logging an issue, be very specific about the problem and the
-exact change and wording that you would like to suggest. The easier
-you make changing the spec, the more likely that your change will be
-placed into the specification.
+A list of bugs is maintained at http://www.w3.org/2005/Incubator/webid/track/
+
+You must be a members of the WebID XG to create new bugs in the tracker, however
+anyone can follow up on existing issues by mentioning the issue number
+(e.g. WebID-ISSUE-33) in the title or the body of any email sent to the
+WebId XG mailing list . These emails will automatically be listed in the
+relevant issues in the tracker.
+
+When logging an issue, be very specific about the problem and the exact change
+and wording that you would like to suggest. The easier you make changing the
+spec, the more likely that your change will be placed into the specification.
Contributing
------------
To directly contribute to the specification:
-1. You MUST modify the 'index-respec.html' file via github - it is the
+1. You MUST modify the 'index-respec.html' file via hg or git - it is the
primary source document.
-2. You MUST agree to transferring the specification text to a governing
- specification body such as the IETF or W3C when the time comes to
- transition the documents to an official specification.
+2. You MUST agree to transferring the specification text to the governing
+ specification body W3C when the time comes to transition the documents to an
+ official specification.
3. You MUST NOT add in any text that you know to be in violation of a trade
secret, patent or other form of intellectual property.
-4. Understand that this will be a patent and royalty-free specification and
- no payment will be made to any of the editors, authors or contributors. That
+4. Understand that this will be a patent and royalty-free specification and no
+ payment will be made to any of the editors, authors or contributors. That
said, millions of people will be thankful for your contribution in ensuring
that the web continutes to be accessible in a patent and royalty-free way.
5. You will want to become familiar with ReSpec before you edit the
'index-respec.html' file. Documentation for respec is available here:
http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
-
+6. Make small commits so that they can be reviewed more easily. Avoid mixing
+ editorial changes and style changes in the same commit.
+7. The respec source document uses an 80 character line limit except for long
+ URIs or code snippets. Trailing whitespaces should be stripped to avoid
+ people who strip them automatically to make unintended changes when saving
+ a file.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/spec/architecture-respec.html Mon Jun 13 18:58:43 2011 +0200
@@ -0,0 +1,361 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>WebID Architecture 1.0</title>
+ <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+<style type='text/css'>
+code { font-family: monospace; }
+
+span.hilite { color: red; /* font-weight: bold */ }
+
+li p { margin-top: 0.3em;
+ margin-bottom: 0.3em; }
+
+div.explanation { background-color: #ADD8E6;
+ width: 80%;
+ margin: 12px; padding: 8px; }
+div.explanation li { margin-top: 8px; }
+div.explanation dd { margin: 4px; }
+
+.adef {
+ font-family: monospace;
+ font-weight: bold;
+ color: #ff4500 !important;
+}
+
+.aref {
+ font-family: monospace;
+ font-weight: bold;
+ color: #ff4500 !important;
+}
+
+span.entity { color: red; }
+
+span.element { color: green; }
+</style>
+
+ <script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script>
+<!-- <script src='/ReSpec.js/js/respec.js' class='remove'></script> -->
+ <script class='remove'>
+ var preProc = {
+ apply: function(c) {
+ // process the document before anything else is done
+ var refs = document.querySelectorAll('adef') ;
+ for (var i = 0; i < refs.length; i++) {
+ var item = refs[i];
+ var p = item.parentNode ;
+ var con = item.innerHTML ;
+ var sp = document.createElement( 'dfn' ) ;
+ var tit = item.getAttribute('title') ;
+ if (!tit) {
+ tit = con;
+ }
+ sp.className = 'adef' ;
+ sp.title=tit ;
+ sp.innerHTML = con ;
+ p.replaceChild(sp, item) ;
+ }
+ refs = document.querySelectorAll('aref') ;
+ for (var i = 0; i < refs.length; i++) {
+ var item = refs[i];
+ var p = item.parentNode ;
+ var con = item.innerHTML ;
+ var sp = document.createElement( 'a' ) ;
+ sp.className = 'aref' ;
+ sp.setAttribute('title', con);
+ sp.innerHTML = '@'+con ;
+ p.replaceChild(sp, item) ;
+ }
+ // local datatype references
+ refs = document.querySelectorAll('ldtref') ;
+ for (var i = 0; i < refs.length; i++) {
+ var item = refs[i];
+ if (!item) continue ;
+ var p = item.parentNode ;
+ var con = item.innerHTML ;
+ var ref = item.getAttribute('title') ;
+ if (!ref) {
+ ref = item.textContent ;
+ }
+ if (ref) {
+ ref = ref.replace(/\n/g, '_') ;
+ ref = ref.replace(/\s+/g, '_') ;
+ }
+ var sp = document.createElement( 'a' ) ;
+ sp.className = 'datatype';
+ sp.title = ref ;
+ sp.innerHTML = con ;
+ p.replaceChild(sp, item) ;
+ }
+ // external datatype references
+ refs = document.querySelectorAll('dtref') ;
+ for (var i = 0; i < refs.length; i++) {
+ var item = refs[i];
+ if (!item) continue ;
+ var p = item.parentNode ;
+ var con = item.innerHTML ;
+ var ref = item.getAttribute('title') ;
+ if (!ref) {
+ ref = item.textContent ;
+ }
+ if (ref) {
+ ref = ref.replace(/\n/g, '_') ;
+ ref = ref.replace(/\s+/g, '_') ;
+ }
+ var sp = document.createElement( 'a' ) ;
+ sp.className = 'externalDFN';
+ sp.title = ref ;
+ sp.innerHTML = con ;
+ p.replaceChild(sp, item) ;
+ }
+ // now do terms
+ refs = document.querySelectorAll('tdef') ;
+ for (var i = 0; i < refs.length; i++) {
+ var item = refs[i];
+ if (!item) continue ;
+ var p = item.parentNode ;
+ var con = item.innerHTML ;
+ var ref = item.getAttribute('title') ;
+ if (!ref) {
+ ref = item.textContent ;
+ }
+ if (ref) {
+ ref = ref.replace(/\n/g, '_') ;
+ ref = ref.replace(/\s+/g, '_') ;
+ }
+ var sp = document.createElement( 'dfn' ) ;
+ sp.title = ref ;
+ sp.innerHTML = con ;
+ p.replaceChild(sp, item) ;
+ }
+ // now term references
+ refs = document.querySelectorAll('tref') ;
+ for (var i = 0; i < refs.length; i++) {
+ var item = refs[i];
+ if (!item) continue ;
+ var p = item.parentNode ;
+ var con = item.innerHTML ;
+ var ref = item.getAttribute('title') ;
+ if (!ref) {
+ ref = item.textContent ;
+ }
+ if (ref) {
+ ref = ref.replace(/\n/g, '_') ;
+ ref = ref.replace(/\s+/g, '_') ;
+ }
+
+ var sp = document.createElement( 'a' ) ;
+ var id = item.textContent ;
+ sp.className = 'tref' ;
+ sp.title = ref ;
+ sp.innerHTML = con ;
+ p.replaceChild(sp, item) ;
+ }
+ }
+ } ;
+
+
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ // embed RDFa data in the output
+ doRDFa: true,
+ specStatus: "ED",
+ diffTool: "http://www3.aptest.com/standards/htmldiff/htmldiff.pl",
+
+ // the specifications short name, as in http://www.w3.org/TR/short-name/
+ shortName: "webid",
+ subtitle: "Web Identification and Discovery",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2009-08-06",
+ copyrightStart: "2010",
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ previousPublishDate: "2010-08-09",
+ previousMaturity: "unofficial",
+ previousURI: "http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20100809",
+
+
+ // if there a publicly available Editors Draft, this is the link
+ edDraftURI: "http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20110210",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ['http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css'],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Manu Sporny", mailto:"msporny@digitalbazaar.com",
+ company: "Digital Bazaar, Inc.", companyURL: "http://blog.digitalbazaar.com/" },
+ { name: "Toby Inkster", url: "http://tobyinkster.co.uk/" },
+ { name: "Henry Story", url: "http://bblfish.net/" },
+ { name: "Bruno Harbulot", url: "http://blog.distributedmatter.net/" },
+ { name: "Reto Bachmann-Gmür", url: "http://trialox.org/" }
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ authors: [
+ { name: "Manu Sporny", mailto:"msporny@digitalbazaar.com",
+ company: "Digital Bazaar, Inc.", companyURL: "http://blog.digitalbazaar.com/" },
+ { name: "Toby Inkster", url: "http://tobyinkster.co.uk/" },
+ { name: "Henry Story", url: "http://bblfish.net/" },
+ { name: "Bruno Harbulot", url: "http://blog.distributedmatter.net/" },
+ { name: "Reto Bachmann-Gmür", url: "http://trialox.org/" }
+ ],
+
+// errata: 'http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata',
+
+ // name of the WG
+ wg: "WebID XG",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2005/Incubator/webid/",
+
+ // name (with the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-xg-webid",
+
+ // alternate formats for this document
+ alternateFormats: [
+ { uri: 'http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20110210/diff-20100809.html',
+ label: "Diff from previous Editors Draft" }],
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/44350/status",
+ maxTocLevel: 4,
+ preProcess: [ preProc ]
+ };
+
+
+ function updateExample(doc, content) {
+ // perform transformations to make it render and prettier
+ content = content.replace(/<!--/, '');
+ content = content.replace(/-->/, '');
+ content = doc._esc(content);
+ content = content.replace(/\*\*\*\*([^*]*)\*\*\*\*/g, '<span class="hilite">$1</span>') ;
+ return content ;
+ }
+
+ function updateDTD(doc, content) {
+ // perform transformations to
+ // make it render and prettier
+ content = '<pre class="dtd">' + doc._esc(content) + '</pre>';
+ content = content.replace(/!ENTITY % ([^ \t\r\n]*)/g, '!ENTITY <span class="entity">% $1</span>');
+ content = content.replace(/!ELEMENT ([^ \t$]*)/mg, '!ELEMENT <span class="element">$1</span>');
+ return content;
+ }
+
+ function updateSchema(doc, content) {
+ // perform transformations to
+ // make it render and prettier
+ content = '<pre class="dtd">' + doc._esc(content) + '</pre>';
+ content = content.replace(/<xs:element\s+name="([^&]*)"/g, '<xs:element name="<span class="element" id="schema_element_$1">$1</span>"') ;
+ return content;
+ }
+
+ function updateTTL(doc, content) {
+ // perform transformations to
+ // make it render and prettier
+ content = '<pre class="sh_sourceCode">' + doc._esc(content) + '</pre>';
+ content = content.replace(/@prefix/g, '<span class="sh_keyword">@prefix</span>');
+ return content;
+ }
+ </script>
+ </head>
+ <body>
+ <section id='abstract'>
+
+<p>Webid gives you reasons to believe that your communication partner is the subject in your universe
+of discourse they claim to be.
+</p>
+</section>
+
+
+<section id="identity">
+<h2>Identity</h2>
+
+<p>....</p>
+
+</section>
+
+<section id="end2end">
+<h2>End to end security</h2>
+
+<p>The "layer cake" of the web models security as something transcending all layers from the serialzed data to trust, unlike IPSec WebId isn't a security infrastructure at the lower levels of the stack, it doesn't hide away security from the user and even the application. This means that it allows the user to make informed decisions on whom to trust and whom to share secrets with.</p>
+
+<p>....</p>
+
+</section>
+
+
+<section id="linkeddata">
+<h2>Sharing believes with RDF and linked data</h2>
+
+<p>....</p>
+
+</section>
+
+<section>
+<h1>Preconditions</h1>
+
+<section>
+<h1>Terminology</h1>
+
+<dl>
+
+
+<dt><tdef>WebID URI</tdef></dt>
+<dd>A URI identifying a participant in a universe of discourse.</dd>
+
+<dt><tdef>WebID Profile</tdef></dt>
+<dd>A document associating a <tref>WebId URI</tref> to a <tref>public key</tref>.</dd>
+
+<dt><tdef>public key</tdef></dt>
+<dd>A widely distributed cryptographic key that can be used to verify
+digital signatures and encrypt data between a sender and a receiver. A public
+key is always included in an <tref>Identification Certificate</tref>.</dd>
+</dl>
+
+
+</section>
+
+<section class='informative' id="acknowledgements">
+<h1>Acknowledgments</h1>
+
+<p>The following people have been instrumental in providing thoughts, feedback,
+reviews, criticism and input in the creation of the WebId architecture:</p>
+
+<ul>
+<li>Tim Berners-Lee</li>
+<li>Sarven Capadisli</li>
+<li>Melvin Carvalho</li>
+<li>Michael Hausenblas</li>
+<li>Kingsley Idehen</li>
+<li>Ian Jacobi</li>
+<li>Nathan Rixham</li>
+<li>Seth Russell</li>
+<li>Jeff Sayre</li>
+<li>Peter Williams</li>
+</ul>
+
+</section>
+ </body>
+</html>
+
--- a/spec/index-respec.html Mon Jun 13 18:54:10 2011 +0200
+++ b/spec/index-respec.html Mon Jun 13 18:58:43 2011 +0200
@@ -236,7 +236,7 @@
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
- wgPatentURI: "http://www.w3.org/2004/01/pp-impl/44350/status",
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/46065/status",
maxTocLevel: 4,
preProcess: [ preProc ]
};
@@ -387,9 +387,10 @@
Using a process made popular by OpenID, we show how one can tie a User
Agent to a URI by proving that one has write access to the URI.
WebID is an authentication protocol which uses X.509
-certificates to associate a User Agent (Browser) to a Person identified via a URI.
-A WebID profile can also be used for OpenID, WebId provides a few additional features such as
-trust management via digital signatures, and free-form
+certificates to associate a User Agent (Browser) to a Person identified
+via a URI.
+A WebID profile can also be used for OpenID, WebID provides a few additional
+features such as trust management via digital signatures, and free-form
extensibility via RDF. By using the existing SSL certificate exchange
mechanism, WebID integrates smoothly with existing Web browsers, including
browsers on mobile devices. WebID also permits automated session login
@@ -417,16 +418,16 @@
may also be a peer on a peer-to-peer network.</dd>
<dt><tdef>Identification Agent</tdef></dt>
-<dd>Provides identification credentials to a <tref>Verification Agent</tref>. The
-<tref>Identification Agent</tref> is typically also a User Agent.</dd>
+<dd>Provides identification credentials to a <tref>Verification Agent</tref>.
+The <tref>Identification Agent</tref> is typically also a User Agent.</dd>
<dt><tdef>Identification Certificate</tdef></dt>
<dd>An X.509 [[!X509V3]] Certificate that MUST contain a
<code>Subject Alternative Name</code> extension with at least one URI entry
identifying the <tref>Identification Agent</tref>. This URI SHOULD be
-dereference-able and result in a document containing RDF data. For example,
-a certificate identifying the WebID URI <code>http://example.org/webid#public</code>
-would contain the following:
+dereference-able and result in a document containing RDF data.
+For example, a certificate identifying the WebID URI
+<code>http://example.org/webid#public</code> would contain the following:
<pre>
X509v3 extensions:
...
@@ -477,7 +478,8 @@
<p>For example, if a user Joe controls <code>http://joe.example/profile</code>,
then his WebID can be <code>http://joe.example/profile#me</code></p>
-<p class="issue">explain why the WebID URI is different from the URI of the WebID profile document.</p>
+<p class="issue">explain why the WebID URI is different from the URI of the
+WebID profile document.</p>
<p>As an example to use throughout this specification here is the
following certificate as an output of the openssl program.</p>
@@ -540,9 +542,15 @@
</pre>
</p>
<p class="issue">Should we formally require the Issuer to be
- O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority. This was discussed on the list as allowing servers to distinguish certificates that are foaf+Ssl enabled from others. Will probably need some very deep TLS thinking to get this right.</p>
+O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority.
+This was discussed on the list as allowing servers to distinguish certificates
+that are foaf+Ssl enabled from others. Will probably need some very deep TLS
+thinking to get this right.</p>
<p class="issue">discuss the importance for UIs of the CN</p>
-<p class="issue">The above certificate is no longer valid, as I took an valid certificate and change the time and WebID. As a result the Signatiure is now false. A completely valid certificate should be generated to avoid nit-pickers picking nits</p>
+<p class="issue">The above certificate is no longer valid, as I took an valid
+certificate and change the time and WebID. As a result the Signatiure is now
+false. A completely valid certificate should be generated to avoid nit-pickers
+picking nits</p>
</section>
@@ -550,17 +558,25 @@
<h1>Publishing the WebID Profile Document</h1>
<p>The <tref>WebID Profile</tref> document MUST expose the relation between the
-<tref>WebID URI</tref> and the <tref>Identification Agent</tref>'s <tref>public key</tref>s
-using the <code>cert</code> and <code>rsa</code> ontologies, as well as the
-<code>cert</code> or <code>xsd</code> datatypes. The set of relations to be
-published at the <tref>WebID Profile</tref> document can be presented in a
-graphical notation as follows.</p>
+<tref>WebID URI</tref> and the <tref>Identification Agent</tref>'s
+<tref>public key</tref>s using the <code>cert</code> and <code>rsa</code>
+ontologies, as well as the <code>cert</code> or <code>xsd</code> datatypes.
+The set of relations to be published at the <tref>WebID Profile</tref> document
+can be presented in a graphical notation as follows.</p>
<img alt="Web ID graph" src="img/WebIdGraph.jpg"/>
-<p>The document can publish many more relations than are of interest to the WebID protocol, as shown in the above graph by the grayed out relations.</p>
-<p>The encoding of this graph is immaterial to the protocol, so long as a well known mapping to the format of the representation to such a graph can be found. Below we discuss the most well known formats, and a method for dealing with new unknown formats as they come along.</p>
-<p>The WebID provider must publish the graph of relations in one of the well known formats, though he may publish it in a number of formats to increase the useabulity of his site using Content Negotations.</p>
-<p class="issue">Add content negoatiation pointers</p>
-<p>It is particularly useful to have one of the representations be in HTML or XHTML even if it is not marked up in RDFa as this allows people using a web browser to understand what the information at that URI represents.</p>
+<p>The document can publish many more relations than are of interest to the
+WebID protocol, as shown in the above graph by the grayed out relations.</p>
+<p>The encoding of this graph is immaterial to the protocol, so long as a well
+known mapping to the format of the representation to such a graph can be found.
+Below we discuss the most well known formats, and a method for dealing with new
+unknown formats as they come along.</p>
+<p>The WebID provider must publish the graph of relations in one of the well
+known formats, though he may publish it in a number of formats to increase the
+usability of his site using content negotiations.</p>
+<p class="issue">Add content negotiation pointers</p>
+<p>It is particularly useful to have one of the representations be in HTML or
+XHTML even if it is not marked up in RDFa as this allows people using a
+web browser to understand what the information at that URI represents.</p>
<section class='normative'>
<h1>Turtle</h1>
<p>A widely used format for writing RDF graphs is the Turtle notation. </p>
@@ -647,7 +663,11 @@
</html>
</pre>
</p>
-<p>If a WebId provider would rather prefer not to mark up his data in RDFa, but just provide a human readable format for users and have the RDF graph appear in a machine readable format such as RDF/XML then he MAY publish the link from the HTML to a machine readable format (it this is available at a dedicated URI) as follows:</p>
+<p>If a WebID provider would rather prefer not to mark up his data in RDFa, but
+just provide a human readable format for users and have the RDF graph appear
+in a machine readable format such as RDF/XML then he MAY publish the link from
+the HTML to a machine readable format (it this is available at a dedicated URI)
+as follows:</p>
<p class="example">
<pre>
<html>
@@ -661,13 +681,15 @@
</section>
<section>
<h1>In RDF/XML</h1>
-<p>RDF/XML is easy to generate automatically from structured data, be it in object notiation or in relational databases. Parsers for it are also widely available.</p>
+<p>RDF/XML is easy to generate automatically from structured data, be it in
+object notiation or in relational databases. Parsers for it are also widely
+available.</p>
<p class="issue">TODO: the dsa ontology</p>
</section>
<section>
<h1>In Portable Contacts format using GRDDL</h1>
<p class="issue">TODO: discuss other formats and GRDDL, XSPARQL options for xml formats</p>
- <p class="issue">summarize and point to content negotiation documents</p>
+<p class="issue">summarize and point to content negotiation documents</p>
</section>
</section>
</section>
@@ -702,7 +724,8 @@
<tref>public key</tref> information associated with at least one of the claimed
<tref>WebID URI</tref>s. The <tref>Verification Agent</tref> MAY attempt to
verify more than one claimed <tref>WebID URI</tref>.
-This verification process SHOULD occur either by dereferencing the <tref>WebID URI</tref> and
+This verification process SHOULD occur either by dereferencing the
+<tref>WebID URI</tref> and
extracting RDF data from the resulting document, or by utilizing a cached
version of the RDF data contained in the document or other data source that is
up-to-date and trusted by the <tref>Verification Agent</tref>. The processing
@@ -721,11 +744,13 @@
of <tref>public key</tref>s associated with the claimed <tref>WebID URI</tref>,
the <tref>Verification Agent</tref> MUST attempt to verify another claimed
<tref>WebID URI</tref>. The authentication MUST fail if no matching
-<tref>public key</tref> is found among all the claimed <tref>WebID URI</tref>s.</li>
+<tref>public key</tref> is found among all the claimed
+<tref>WebID URI</tref>s.</li>
<li>The <tref>Verification Agent</tref> verifies that the
-<tref>Identification Agent</tref> owns the private key corresponding to the public key sent in the
-<tref>Identification Certificate</tref>. This SHOULD be fulfilled by performing TLS mutual-authentication
+<tref>Identification Agent</tref> owns the private key corresponding to the
+public key sent in the <tref>Identification Certificate</tref>.
+This SHOULD be fulfilled by performing TLS mutual-authentication
between the <tref>Verification Agent</tref> and the
<tref>Identification Agent</tref>.
If the <tref>Verification Agent</tref> does not have access to the TLS layer,
@@ -739,7 +764,8 @@
profile document graph given above then the <tref>Verification Agent</tref>
knows that the <tref>Identification Agent</tref> is indeed identified by the
<tref>WebID URI</tref>. The verification is done by querying the
-Personal Profile graph as specified in <a href="#extracting-webid-uri-details">querying the RDF graph</a>.</li>
+Personal Profile graph as specified in
+<a href="#extracting-webid-uri-details">querying the RDF graph</a>.</li>
</ol>
<p>
@@ -777,14 +803,15 @@
<section class='normative'>
<h2>Processing the WebID Profile</h2>
-<p>A <tref>Verification Agent</tref> MUST be able to process documents in RDF/XML
-[[!RDF-SYNTAX-GRAMMAR]] and XHTML+RDFa [[!XHTML-RDFA]]. A server responding to
-a <tref>WebID Profile</tref> request SHOULD be able to deliver at least RDF/XML
-or RDFa. The <tref>Verification Agent</tref> MUST set the Accept-Header to request
-<code>application/rdf+xml</code> with a higher priority than <code>text/html</code>
-and <code>application/xhtml+xml</code>. If the server answers such a request
-with an HTML representation of the resource, this SHOULD describe the WebId Profile
-with RDFa.
+<p>A <tref>Verification Agent</tref> MUST be able to process documents in
+RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and XHTML+RDFa [[!XHTML-RDFA]].
+A server responding to a <tref>WebID Profile</tref> request SHOULD be able
+to deliver at least RDF/XML or RDFa.
+The <tref>Verification Agent</tref> MUST set the Accept-Header to request
+<code>application/rdf+xml</code> with a higher priority than
+<code>text/html</code> and <code>application/xhtml+xml</code>. If the server
+answers such a request with an HTML representation of the resource, this SHOULD
+describe the WebID Profile with RDFa.
</p>
<p class="issue">This section will explain how a Verification Agent extracts
@@ -795,13 +822,14 @@
<h2>Verifying the WebID is identified by that public key</h2>
<p>
-There are number of different ways to check that the public key given in the X.509
-certificate against the one provided by the <tref>WebID Profile</tref> or another
-trusted source, the essence is checking that the graph of relations in the
-Profile contains a pattern of relations.
+There are number of different ways to check that the public key given in the
+X.509 certificate against the one provided by the <tref>WebID Profile</tref> or
+another trusted source, the essence is checking that the graph of relations in
+the Profile contains a pattern of relations.
</p>
<p>Assuming the public key is an RSA key, and that its modulus is
- "9D79BFE2498..." and exponent "65537" then the following SPARQL query could be used:
+"9D79BFE2498..." and exponent "65537" then the following SPARQL query could
+be used:
</p>
<pre class='example'>
PREFIX cert: <http://www.w3.org/ns/auth/cert#>
@@ -819,12 +847,17 @@
values may be expressed with different xsd and cert datatypes which must all
be supported by <tref>VerificationAgent</tref>s. The cert datatypes allow
the numerical expression to be spread over a number of lines, or contain
-arbitrary characters such as "9D ☮ 79 ☮ BF ☮ E2 ☮ F4 ☮ 98 ☮..." . The datatype
+arbitrary characters such as "9D ☮ 79 ☮ BF ☮ E2 ☮ F4 ☮ 98 ☮..." . The datatype
itself need not necessarily be expressed in cert:hex, but could use a number of
xsd integer datatype notations, cert:int or future base64 notations.
</p>
<p class="issue">Should we define the base64 notation?</p>
-<p>If the SPARQL endpoint doesn't provide a literal inferencing engine, then the modulus should be extracted from the graph, normalised into a big integer (integers without an upper bound), and compared with the values given in the public key certificate. After replacing the <code>?webid</code> variable in the following query with the required value the <tref>Verifying Agent</tref> can query the Profile Graph with</p>
+<p>If the SPARQL endpoint doesn't provide a literal inferencing engine, then
+the modulus should be extracted from the graph, normalised into a big integer
+(integers without an upper bound), and compared with the values given in the
+public key certificate. After replacing the <code>?webid</code> variable in the
+following query with the required value the <tref>Verifying Agent</tref> can
+query the Profile Graph with</p>
<pre class='example'>
PREFIX cert: <http://www.w3.org/ns/auth/cert#>
PREFIX rsa: <http://www.w3.org/ns/auth/rsa#>
@@ -836,8 +869,10 @@
}
</pre>
<p>Here the verification agent must check that one of the answers for ?m and ?e
-matches the integer values of the modulus and exponent given in the public key in the certificate.</p>
-<p class="issue"> The public key could be a DSA key. We need to add an ontology for DSA too. What other cryptographic ontologies should we add?</p>
+matches the integer values of the modulus and exponent given in the public key
+in the certificate.</p>
+<p class="issue"> The public key could be a DSA key. We need to add an ontology
+for DSA too. What other cryptographic ontologies should we add?</p>
</section>
@@ -903,8 +938,8 @@
<p>Personal details are the most common requirement when registering an
account with a website. Some of these pieces of information include an e-mail
address, a name and perhaps an avatar image. This section includes
-properties that SHOULD be used when conveying key pieces of personal
-information but are NOT REQUIRED to be present in a <tref>WebID Profile</tref>:</p>
+properties that SHOULD be used when conveying key pieces of personal information
+but are NOT REQUIRED to be present in a <tref>WebID Profile</tref>:</p>
<dl>
<dt>foaf:mbox</dt>
@@ -922,8 +957,8 @@
<p>Cryptographic details are important when <tref>Verification Agent</tref>s
and <tref>Identification Agent</tref>s interact. The following properties
-SHOULD be used when conveying cryptographic information in <tref>WebID Profile</tref>
-documents:</p>
+SHOULD be used when conveying cryptographic information in
+<tref>WebID Profile</tref> documents:</p>
<dl>
<dt>rsa:RSAPublicKey</dt>
@@ -942,12 +977,26 @@
<section class='appendix informative' id="history">
<h1>Change History</h1>
-<p><a href="https://dvcs.w3.org/hg/WebID/rev/6b60d7335151">2011-02-10</a> Move to <a href="http://www.w3.org/2005/Incubator/webid/">W3C WebID XG</a>. Updates from previous unofficial WebID group include changes on RDF/XML publishing in HTML, clarification on multiple SAN URIs and WebID verification steps.
+<p><a href="https://dvcs.w3.org/hg/WebID/rev/6b60d7335151">2011-02-10</a>
+Move to <a href="http://www.w3.org/2005/Incubator/webid/">W3C WebID XG</a>.
+Updates from previous unofficial WebID group include changes on
+RDF/XML publishing in HTML, clarification on multiple SAN URIs and
+WebID verification steps.
</p>
-<p><a href="https://dvcs.w3.org/hg/WebID/rev/dc93b6bbc538">2010-08-09</a> Updates from WebID community: moved OpenID/OAuth sections to separate document, switched to the URI terminology instead of URL, added "Creating the certificate" and "Publishing the WebID Profile document" sections with a WebID graph and serializations in Turtle and RDFa, improved SPARQL queries using literal notation with cert datatypes, updated list of contributors, and many other fixes.</p>
-<p><a href="https://dvcs.w3.org/hg/WebID/rev/4aef27947dec">2010-07-25</a> Added WebID Profile section.</p>
-<p><a href="https://dvcs.w3.org/hg/WebID/rev/805d44635286">2010-07-18</a> Updates from WebID community related to RDF/XML support, authentication sequence corrections, abstract and introduction updates.</p>
-<p><a href="https://dvcs.w3.org/hg/WebID/rev/25ba7f596f07">2010-07-11</a> Initial version.</p>
+<p><a href="https://dvcs.w3.org/hg/WebID/rev/dc93b6bbc538">2010-08-09</a>
+Updates from WebID community: moved OpenID/OAuth sections to separate document,
+switched to the URI terminology instead of URL, added "Creating the certificate"
+and "Publishing the WebID Profile document" sections with a WebID graph and
+serializations in Turtle and RDFa, improved SPARQL queries using literal
+notation with cert datatypes, updated list of contributors,
+and many other fixes.</p>
+<p><a href="https://dvcs.w3.org/hg/WebID/rev/4aef27947dec">2010-07-25</a>
+Added WebID Profile section.</p>
+<p><a href="https://dvcs.w3.org/hg/WebID/rev/805d44635286">2010-07-18</a>
+Updates from WebID community related to RDF/XML support, authentication sequence
+corrections, abstract and introduction updates.</p>
+<p><a href="https://dvcs.w3.org/hg/WebID/rev/25ba7f596f07">2010-07-11</a>
+Initial version.</p>
</section>
<section class='informative' id="acknowledgements">