Julie Garrone
Baptiste Lafontaine
Supervisors:
Olivier Berger
Andrei Sambra
Table Of Contents
People have been using login and password to register and identify themselves on Internet for many years, but is it the best solution? Large companies, such as Google, are looking for better and more secure ways to identify a user (two steps login for instance).
Aren't you tired of remembering long and complicated passwords (or worse, are you using the same password everywhere)? To enter your name and address every time you want to join a website?
Moreover do you trust multinational companies to hold all your personal data? No? Then...
Then you will love WebID!
The WebID protocol provides a way of identifying a user without the need of the couple username/password. In addition, the user is in control of his own data because he can store it anywhere he wants.
This protocol could be part of the solution of the current issue of the distributed social networks. The idea developed here is to enable people to control the access of their own information by having their own server which contains all their personal data. Therefore the social network has no more control over your data.
The initial topic, available here (document provided in French), expressed two guidelines to follow:
After discussing the subject, we decided doing a state of the art of WebID technology would become part of our work too.
A WebID ,WebIDs and the WebID Protocol [Online]. Available: http://www.w3.org/wiki/WebID is a way to uniquely identify a person, company, organization, or other agent using a URI. The term "WebID" was coined by Dan Brickley and Tim Berners-Lee in 2000.
The WebID Protocol authenticates a digital identity by allowing an Agent (e.g., a Web Browser) to prove possession of a private key, whose corresponding public key is tightly bound to this WebID. The private key is usually associated with a "certificate" on the user's computer, while the public key and WebID are defined in the FOAF file of the subject and described by a URI in the certificate.
In order to give the full context of a Client interaction with a Server we will illustrate the protocol with the following sequence diagram.
It's worth emphasizing that most of the identification is done by TLS. Only steps 5 and 6 are specific to WebID.
We have already seen that WebID uses TLS protocol in order to verify both the server and the client, let's take a deeper look into TLS.
Transport Layer Security (TLS) T. Dierks, E. Rescorla,The Transport Layer Security (TLS) Protocol, Version 1.2, August 2008; http://www.w3.org/wiki/WebID and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet.
The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. The goals of the TLS protocol is to provide: cryptographic security, interoperability, extensibility, relative efficiency. Therefore it provides these different security aspectsS. Thomas, Ssl & Tls Essentials: Securing the Web. New York: Wiley Computer Publishing, 2000.:
In the WebID protocol, the client must have a X509 certificateR. Housley et al., Internet X.509 Public Key Infrastructure, IETF RFC 5280, May 2008; http://www.ietf.org/rfc/rfc5280.txt with a subject alternative name URI entry that dereferences to a document which contains the public key for that certificate.
For now, one of the main criticism is that TLS on server side is required to use WebID. Although it is a problem, there are more and more people believing that the web will be turned into "HTTPS only" soon , [Online]. Available: http://vitobotta.com/why-isnt-ssl-on-by-default-for-all-websites/. For instance, Google or Facebook are now available in "SSL only" mode.
FOAF is a machine-readable ontology based on the Resource Description Framework (RDF) and describing persons, their activities and their relations to other people and objects. It allows groups of people to describe social networks without the need for a centralised database: indeed all the relations between people are described in FOAF files.
The FOAF Ontology is used in the WebID protocol with accordance to the following graph:
In this graph the WebID URI is https://bob.example/profile#me. The profile is located at the URL https://bob.example/profile.
The only mandatory field for a WebID is cert:key (composed of cert:modulus and cert:exponent): these fields must contain the public key(s) of the user. All other fields (name, birth etc.) are completely optionals.
Because WebID uses a RDF file to store the public key of the user on server side, most of WebID users store their key within a FOAF file to describe themselves.
Thanks to the extensibility of RDF, it can store any information.
For now, FOAF file seems to be the best choice because it can contains every data to identify a person, but we can imagine that other application specific data could be included.
Despite the fact the client part of WebID is based on the quite old TLS client certificate, this may require some browser improvement in order to be more widely used.
In appendix 1, you can find screen captures of user certificate selection. Firefox is giving the most complicated window with a lot of information that is not very useful for the user, whereas Internet Explorer is showing a pretty nice window. Even if it seemss like a detail, it's important escpecially if it is to be used by the mass.
Another requirement is a way for the website to interact with the browser TLS stack. There is no clear standard to say what is possible: for instance it's currently possible to logout from WebID with Firefox or Internet Explorer but not with Chrome. Indeed the JavaScript object window.crypto (and in particular it's method window.crypto.logout()) is note standardized by any organization. This may change because there is an HTML5 related group, the Web Crypto API community group which is working on this issue in order to formalize what functions the browser should provide. Results of this group, and quick implementation by most browser manufacturers will be decisive for WebID.
There are a few other ways to simplify and improve user login, some are standardized, some aren't.
The closest implementation is BrowserID, currently developed through the Mozilla foundation. The main difference is that BrowserID uses Javascript and a JSON certificate in order to work (whereas WebID uses TLS) and it uses the e-mail as the identifier. BrowserID require modification in browser and support from email providers.
By the way, WebID is not incompatible with this login system. For instance, OpenID could be used with WebID: for now, most OpenID providers use classic login/password, but we can imagine that the user login to the OpenID endpoint with WebID, then the classic OpenID process continues. This could be useful in order to prepare the transition to WebID because OpenID is quite widely deployed on Internet (for instance all Google ID are OpenID too).
Getting the status of a W3C Recommendation helps to make the web a better place
by allowing both developers and users to have a better web experience. In January 2011, during one year, WebID was developed through a W3C Incubator Group (XG) which is usually (but not mandatory) the first step in the recommendation redaction process. Members of Incubator Groups are authorized to use W3C infrastructures (such as mailing-list, wiki, bug tracker, ...) and allows to gather experts and every people interested in a technology in one location. It's a process open to anyone, for free; but because the process is based on consensus, it's quite hard to make decision with a large number of people.
Most of discussions are made through the public-xg-webid@w3.org mailing list. There are also Teleconference meetings (accessible by phone, SIP, IRC...) every month which helps do decide what to focus on during the following weeks.
On January 2012, WebID XG was turned into a Community Group (CG). It's not any kind of evolution but the W3C is progressively deleting the concept of XG to CG.
After a chair request, the group can be moved to the W3C Standards Track
: it will be turned into a Working Group (WG). Because subscription to WG are not open: there are two way to join them:
When reaching the recommendation track, the work is far from done. The recommendation will have to gp through these steps Dan Burnett, W3C Recommendation Track [Online]. Available: http://www.w3.org/2011/04/webrtc/wiki/images/5/5c/Webrtc_w3c_rec_track.pdf:
For some standards it can take years to complete this procedure. That's why it's important to have working implementation as soon as possible, even if the recommendation is not complete, in order to spread the standard.
At least before publishing the Candidate recommendation, a test suite shoud be available allowing people doing the implementation to clearly know if their implementation is correct or not. As of January 2012, there is no complete test suite for WebID which leads to problem such as simple implementation considerate that a WebID profile is correct and some considerate that there is a problem.
EARL is an acronym for Evaluation And Report Language. It's a RDF vocabulary defined in a in-development W3C Recommendation (currently in the Last Call process)Shadi Abou-Zahra, Shawn Lawton Henry et al, EARL Overview, [Online]. Available: http://www.w3.org/WAI/intro/earl which provides a way to express tests (including assertions and results) in machine-readable format.
An EARL vocabulary is currently developed within the WebID group in order to formalize a number of tests that must be done in order to verify a WebID identify. The complete ontology currently provides more than twenty tests.
Some examples of the testsHenry Story, Document describing a vocabulary to allow a RelyingParty to make a report on an attempt at a WebID authentication. [Online]. Available: http://www.w3.org/2005/Incubator/webid/earl/RelyingParty.n3:
An example of result, in RDF serialization Notation3 could be:
[] a earl:Assertion; earl:subject _:certificate; earl:test wit:certificateProvidedSAN; earl:result [ a earl:TestResult; dct:description ""; earl:outcome earl:passed;
We can see an RDF blank node representing an EARL assertion. This assertion has a subject, a test and a result. The subject is the certificate, the test is "is there any Subject Alternative Name (SAN) in this certificate?". The result is another anonymous node with the outcome set to "passed", so we know that this test has been passed successfully.
A Java test-suite is currently developed to help developers test their WebID endpoint by sending corrupted certificate or misconceived RDF. For that purpose, the endpoint must reply with an EARL (RDF) document showing what errors/successes it has found.
It's a very important part of the work of the community group which will be decisive.
Node.js (Node) is a software system which aims to produce highly scalable applications. Programs are written in JavaScript. Node is built ontop of Google's V8 engine which is the open source JavaScript engine used for instance in Google Chrome; it currently offers the best performance.
To be highly scalable, Node uses event based programming.
Traditional servers such as Apache spawns a new thread (or use one of a pools) to handle each request. This thread will be used only for this request as long as the whole process is not finished. If other request arrive, they are put in the queue waiting for the thread to be available.
This approach does not provide good performance because of the memory cost of thread (or process) management. In order to scale well, this kind of server must use lots of threads. But large numbers of threads leads to overloading the machine as well as synchronization problems.
Node works differently: it mainly uses an event loop that executes your code in a single thread. This loop handles all incoming connections, that's why potentially long operations (such as network or disk I/O, database queries, etc) must be executed asynchronously (with the use of callback) on worker threads.
In order to defer long operations to other threads, Node supports the brand new HTML5 Web Workers to delegate work to other threads.
Many features of JavaScript help developers to write effective event-driven programs (with a minimum of lines of code). Moreover, the way that Node is coded allows to do this painlessly: there is no thread management nor synchronization functions...
Node is under heavy development: core APIs may change at any time. It could even be an advantage or a problem. An advantage because if bugs are found or new features requested, development teams can react quickly. But it is also a problem when, for example, the number of arguments of a function changes from a version to another: it may require additional work to follow Node's quick development.
npm is Node's package manager which allows to install packages (with the additional possibility to add your own c++ wrappers if needed), and even to publish your own package on a centralized platform. On January 7th 2012, there were more than six thousand packages available which were covering a wide range of functionalities such as template engines, web pages parsing, certificate management... Anyone can publish a package to npm registry with only a few lines.
We also studied different aspects of the distributed social networks that will finally not be implemented in our project. Nevertheless these related technologies could be added to the project in the future in order to develop or improve it.
We studied about how to make the webID protocol as portable as possible. The solution we found was to put the server that contains the FOAF file on a smartphone. Indeed most of us always carry a phone around us with a permanent internet connexion: having all personal information in our phone would be the final stage of "user in control of his data".
Nevertheless for the moment Node.js is not compatible on Android OS, there is only an attempt in development on GitHub but it's not quite ready yet. Indeed it can only run on a modified version of Android.
As seen in the WebID authentication sequence, the access control can be treated during the sixth step. Because users may want to give different information depending on who is asking:
We thus tried to find an ontology in order to be able to control the access to the data on the FOAF file.
We found quite a few ontologies to do the access control:
We have chosen to use the platform GitHub to store our code because of three main reasons:
For intern communication, we used a wiki (powered by dokuwiki, hosted on a personal server, available here) to share the minutes of ours meetings, important links about our research, etc.
To generate our modules's documentation, we used the JSDoc toolkit. It uses in-line annotation (mostly the same as Javadoc) within the code (such as @param to describe a function parameter) to create a user-friendly documentation. An example of HTML output can be found on github.
Before starting to code, we had to make research on many topics related to WebID that where totally unknown to us (RDF and its serialization RDF/XML and Turtle, TLS, X509 certificate, FOAF, ...).
After having a good understanding of these technologies and noticing that there wasn't much information in our native language (French), we created a few articles on Wikipedia to help the spreading of those technologies:
By writing small summaries of these technologies and rephrasing already existing articles, we eventually got a clearer view.
We searched if other people had already done some work on WebID with Node. A Google search did not give any result, neither did a search on GitHub, but someone mentioned an implementation on the WebID XG list. After contacting the author, Antonio Garrote, he put his code on his GitHub account. We have identified one main problem: the lack of RDF library in JavaScript.
There are a few RDF libraries (in pure JavaScript or wrappers to other libs) available on the Internet. The following matrix shows RDF support for the main libraries.
| RDFQuery | RDF parser | rdfstore-js | LinkedData RDFLib | Rdf raptor | |
|---|---|---|---|---|---|
| Last update | 2010 | 2006 | 2012 | 2012 | 2011 |
| Parse (and export) RDF/XML | Yes | Yes | No | Yes | Yes |
| Parse RDFa | Yes | Yes | No | Yes | Yes |
| Parse (and export) N3 (Turtle) | Yes | Yes | Yes | Yes | Yes |
| SparQL (1.0) support | Yes | No | Yes | Yes | No |
| Parallel execution | No | No | Yes | No | Yes |
| Requirement | jQuery | / | Node | / | libraptor v1.4 |
Even if it looks like that there are many libraries, many can be eliminated. RDFQuery is a jQuery plugin, and for now jQuery plugins are not compatible with Node (even if some projects such as jsdom aims to implement the DOM, which is required by jQuery, to node.). RDF parser does not support SparQL which is required to verify the public key.
We have seen in context that Node.js application have to do the least number of operations in the main thread. As a matter of fact the support of WebWorkers of rdfstore-js was decisive even if it did not support RDF/XML. Moreover this module is under development and RDF/XML could be implemented in a near future.
Because most profiles on internet are in RDF/XML, we used a web service that translates RDF/XML to Turtle.
We started working with Node.Js 0.5.10 which didn't had the Subject Alternative Name available in the certificate. After a bug request this has been added to Node for the 0.6.0 beta version.
In order to clearly separate our different modules, we created four different github repositories:
This is our core implementation. It tries to follow the
Our public API is simple, example of basic usage:
var certificate = req.connection.getPeerCertificate(); // Get the CLIENT certificate. In most language, getting this information is as simple // as a method call. if (!_.isEmpty(certificate)) { // The client can decline the demand of the certificate, so the vaiable certificate is empty // in this case, we can't continue the process. var verifAgent = new webid.VerificationAgent(certificate); // Initialize our WebID framework // It basically doesn't do anything // We can notice that the only input used to validate a WebID is the certificate verifAgent.verify(function (success, result) { // The verify method do the whole process // - Getting the file located at Subject Alternative Name // - Getting the public key in this file (exponent and modulus) // - Verifying if this public key equals the key of the certificate // Call the callback if (success) { // In case of success, the 'result' variable contain the complete RDF Profile var foaf = new webid.Foaf(result); var foafFile = foaf.parse(); // Another function of our module is to parse the FOAF // then a few variable are available, such as: // - foafFile.name: contain the name // - foafFile.knows: contain known people } else { // There has been an error during the process // OR // The profile is not valid! } });
We can see that adding WebID login to a website is as easy as 10 lines of code: this is much easier than OpenID for example. Otherwise it requires the server to use TLS.
We have published this module on npm (search.npmjs.org/#/webid): developers who want to use our code, just have to type: npm install webid, and the library (and its dependencies) will be installed on their working directory. They can also declare WebID as a dependency of their own package by declaring "webid" into the package.json file.
This is a simple demo of WebID login using our module.
This demo offers a simple way to test WebID:
Using Node 0.6.x, installation is as simple as: git clone git://github.com/magnetik/node-webid-demo.git to download the code
then: node src/server.js to start the server
Then, using your favorite browser, go to: https://localhost:8081.
It was initially designed to be an EARL endpoint, but we didn't have enough time to implement all tests. Moreover we weren't able to use WebID java test suite correctly.
Almost all developers using Node.js for web usage use the express framework, or at least the middleware Connect. this framework/middleware helps developers program their application without worrying about the underlying considerations such as routes mapping, sessions etc.
Passport is an identification middleware which can be used with connect or express. It's designed to handle many "strategies", from classic login/password, to OpenID, facebook connect, and now... WebID !
Our module is now available as a passport strategy which means that anyone can use it with even less line of code than our "standard" example.
For instance, a local username/password strategy usage using Passport looks like:
passport.use(new LocalStrategy( function(username, password, done) { User.findOne({ username: username, password: password }, function (err, user) { done(err, user); }); } ));
And the modified code which supports WebID:
passport.use(new WebIDStrategy( function(webid, done) { User.findOne({ webid: webid }, function (err, user) { done(err, user); }); } ));
Of course, this code does not use the available FOAF file, but with minor adjustments it could be modified.
In order to implement EARL answer in our node-webid module, we created a module to help generates EARL reports.
Via a simple API that we defined, developers can easily generate an EARL document.
For instance:
var earl = require('earl'); // Creating EARL document Object var earlDocument = new earl.EarlDocument(); // Create an assertion: // whose subject is the certificate // and whose name is wit:certificateProvidedSAN earlDocument.addAssertion(":assert1", ":certificate", "wit:certificateProvidedSAN"); // Tells that this assertion is passed with success // We could has used .failed() too. earlDocument.getAssertion(":assert1").passed();
Will produce:
<assert1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/ns/earl#Assertion> . <assert1> <http://www.w3.org/ns/earl#subject> <certificate> . <assert1> <http://www.w3.org/ns/earl#test> <http://purl.org/dc/terms/certificateProvidedSAN> . <assert1> <http://www.w3.org/ns/earl#result> <assert1Result> . <assert1Result> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/ns/earl#TestResult> . <assert1Result> <http://www.w3.org/ns/earl#outcome> <http://purl.org/dc/terms/passed> .
We started studying the Triple Access Control ontology to implement a server that could serve a different FOAF file depending on who (or which server) is asking.
With the SparQL query in appendix 2, we can construct a new FOAF file by just changing the name "example.com" in the query: it will only contain the field that are annotated as "readable" by "example.com".
The problem was precisely to identify WHO is asking. Indeed during the process, the WebID verifier simply downloads the FOAF file to a distant web server. In order to use our query, the WebID verifier would have to identify itself to the server where the FOAF file is embedded. In a nutshell, for the WebID process, the client identifies himself through WebID to a server, and this server would have to identify itself to another server (some kind of a "mutual identification").
This problem was out of the scope of our project. After a discussion with Andrei Sambra, we decided to stop our investigation at this point.
We used Git submodule S. Chacon, Git book, [Online]. Available: http://book.git-scm.comcapabilities. It allows to declare a directory as a checkout of another project. The main advantage was to separate our main module (node-webid) from our implementations (passport-webid and node-webid-demo).
However using git submodules requires to respect a workflow that is not quite obvious. We will give an example of the submodule usage in node-webid-demo (the "super project").
git submodule add git@github.com:magnetik/node-webid.git /webid/git submodule update --initgit branch master and update git pull because git maintains the submodule as detached HEAD.git commit and git push in the submodule first.git commit and git push in the super projectFollowing the beginning of a future standard was exciting and a good opportunity to understand how a standard is written. Even more because this is the only part of the W3C process which is open to anyone.
Learning a new language and perhaps more important a new architecture (event-driven architecture) is interesting. Moreover JavaScript is more and more used on the web in one hand, with application which can be compared to desktop one (Gmail for instance). And on another hand outside the web as script tool in Gnome Shell or Microsoft Vista's gadget. JavaScript is the 10th most used language according to the TIOBE index, and it's more and more used.
Node.js technology looks promising. Even if we didn't had any benchmark on our own application, it permits to to highly scalable application without having to learn new syntax or operators. Learning Node is easy and the community already very active. For instance we reported a few bugs that have all been fixed within a few days.
WebID is a promising standard but a few barriers are still strong for end-users. For instance the concept of certificate for users, how to handle certificate when not at home? There is no blocking issue, but if an internet major company implement WebID (Google for instance has already implemented OpenID), it would be a great support for the standard. Anyway the recommendation is not quite ready and solutions will be found.
We spent a lot of time in research about RDF, TLS and JavaScript because we started with a 0 level on these technologies. We may have coded more impressive demo using an already known language such as Java.
The main issue we had to face was the lack of good Node.js implementations for RDF. Although this technology is quite old, it's not as widespread as XML for instance.
With more than 400 messages per month, following the mailing list daily was really time consuming, that's why we did not participate much in the discussions.
This report is available under the Creative Common BY-SA 3.0 License. You are free to:
Under these conditions:
You can download it here
It's made with HTML5 + CSS3 and JavaScript to generate some content.
These are screen capture of certificate selection under the main mobile and desktop browsers
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX acl: <http://www.w3.org/ns/auth/acl#>
PREFIX tac: <http://ns.bergnet.org/tac/0.1/triple-access-control#>
PREFIX src: <file:/mci/ei0912/garrone/git/tac/src/data/testXML.rdf#>
CONSTRUCT {src:me ?predicate ?data}
WHERE
{
?group foaf:name "example.com" .
?tacAccess acl:agent ?group .
?tacAccess tac:accessToTriple ?tripleAccessible .
?tripleAccessible tac:mode ?mode .
?tripleAccessible tac:filter ?tmpdata .
{ ?tmpdata tac:predicate ?predicate .
src:me ?predicate ?data .}
UNION
{ ?tmpdata tac:subject ?subject .
OPTIONAL { ?tmpdata tac:predicate ?p .}
FILTER ( !bound(?p) ) .
?subject ?predicate ?data . }
}