The foaf+ssl paradigm shift

passport picture

Foaf+SSL builds on PKI whose paradigmatic example is that of a traveller crossing the frontier and showing his passport. The problem is that this analogy breaks down for foaf+ssl (wiki page) and can make it difficult to understand what is going on. What is required is a paradigm shift, and I will here help walk you through it. (Thanks to a educational exchange with Bruno Harbulot on the foaf-protocols mailing list)

Traditional PKI

So first let us step into the old paradigm. You arrive at a web site. It asks you for your certificate which is somewhat like being asked for a passport at a border. So in this analogy you are playing the role of the traveller who is looking to cross the border (access that resource), and the server is playing the role of border patrol officer, whose job it is to permit you only if you are authorized to do so.

So of course you hand over a certificate. This contains a number of things:

  • Your identifier. This can be the passport number. In X509 it is the Distinguished Name. And with foaf+ssl we have are also making use of the subject alternative name, a WebId.
  • Something to tie the certificate to you. In the case of the passport this would be the photo on the passport which should match your face. In the certificate this role is played by the public key that corresponds to the private key only you posses. The public key that you send is what others see of your face, ie, the photo on the passport, the private key would be your face itself.
  • There may be a few other things written in the passport about you, such as your age, your birthplace, etc...
  • The whole passport is designed to be recogniseable as having been published by the Government which issued it - usually it is also signed by them. And indeed in the certificate space we have the same thing: a Certificate Authority takes the place of the Government and signs your certificate.
By giving over this passport to the officer, or by sending your certificate to the server, you have completed your role in identifying yourself.

The server receiving this certificate, playing the role of the border patrol agent, now himself needs to continue the process:

  • First he must identify you. Ie, his task is given the pasport, to verify the referent of its holder. He can do this simply by verifying that the picture matches your face. In the case of TLS this is done simply through the cryptographic mechanism that established the https connection.
  • Next the officer must verify that the information in the passport is issued by a government agency he trusts. This is the authentication step. (Authentication, from Greek αυθεντικός, real or genuine, from authentes for author) The officer verifies that the passport is genuinely from the government. To do this he verifies the watermarks, checks for signs of tampering, etc... In the case of the server this is very easy to do using encryption. The certificate is signed by the Certificate Authority, in such a way as to make it extremly difficult to tamper with. By verifiying the Certificate integrity and that the signature of the CA matches the one it has on file the server can be confident that the information it is reading was stated by the Authority it trusts. Since it trusts that authority it can believe its contents.
  • Having accepted the contents, it can trust the identifier is of you, and finding that you are not on a blacklist, can authorize you to cross the border.

How the analogy breaks down

The problem with that analogy is that it does not help one to understand foaf+ssl, because with foaf+ssl the certificate presented to the server is self signed, and the identity self created!

self signed certificate

To clearly see how the analogy breaks down, imagine what would happen if we mapped the foaf+ssl back to our border patrol situation. Imagine you arrive happily at the border and the officer asks you for a passport. You give him a piece of paper nicely crafted on your color laser printer at home, with your photo on the right hand side, your self created WebId, a URL you coined a few days before, your name, and your signature below. On the paper you put a nice logo, saying "Issued on 1 Jan 2009 by Me, valid for 1 year."

Now I don't recommend doing this during times of high tension between the countries on either side of the border, or unless you have some serious reason to believe that the officers have a good sense of humor. If they do, you can be certain you will be sent back from where you came from, and not into some more dingy place with bars instead of windows.

A better analogy

So lets leave those dreary, bureaucratic and slow moving border control situations where novelty is frowned upon far behind us. Instead let us try for a different example.

So imagine now you are going to a masked party, where only a preselected group of people were invited, of which you. As you arrive in your RoboCop costume which completely covers your body, and muffles your voice, you present a paper with a note on which is your typewritten ID. Having verified that the person with that ID is indeed authorized to join, the guard at the door asks you to move your right arm up and down three times, which you do. To wiggle your bottom as best you can, which you do. Satisfied that he has identified you, the guard lets you in, and you go party.

According to you, is this guard doing his job correctly? Has he correctly authorized you? Let me add here that the ID you gave him is a public ID and that the list of invited people is also public! What do you think? Because this is really not far from the foaf+ssl solution...

Well it all depends on a how the guard came to ask you to move your hand! Imagine that your ID was the URL <tel:+1.510.931.5491>, and that the guard took out his cell phone and called that number. You, in the depth of your RoboCop costume receive the call. The guard asks: "Hi are you in front of the party now?". You answer "yes", and the guard hears the voice in the phone answer "yes". He asks you to move your right hand up and down three times which you immediately do. He asks you to do the best to wiggle your bottom. Which you do. Now has he not identified you as being <tel:+1.510.931.5491>?

Are you thinking: "well yes, could I - being inside the costume - could I not have just overheard what the guard was saying, even had I not received the call?". If that thought bothers you, then replay the same scenario, but this time change the ID you give over to an email address, and have the guard send you an email, which you receive on your cell phone too. This is something we do all the time when signing up to web sites.

Notice now how this is similar to the foaf+ssl protocol. There you give the guard an https URL, and he queries that URL with an HTTP GET. That returns a response containing your public key, which is the one you used to communicate with the guard, thereby clearly tying you to your ID. Once that link is made, the guard can go straight to the authorization step: are you or are you not in the invited people's list.

The Web of Trust

We have been using email URLs for a long time to identify ourselves on sites. So what does foaf+ssl add that we did not have before? Well it does the same thing in a RESTful manner. REST is the architectural style on which the most successful hypermedia system ever was built. It is designed to make hypermedia easily possible. The advantage of building in this style is that it is very easy to link information together. So just as the original Web made it very easy to link documents together, so by following this style into the hyperdata space, we make it easy to link things together. By making identity RESTful we have layed the basic building blocks to then build a web of trust.

So to illustrate just a little bit more how this works, let us extend the access rules in our example slightly. To be allowed access to the party you either have to be on a list, or you have to be a friend of someone on the list. This just helps regulate the party somewhat, so that there are clear chains of responsibility that can be drawn in case of trouble. This time you are not on the list. You are still in your large RoboCop costume, and the guard calls you to ask you who you know. You say you know <tel:+44-161-275-014>. The skeptical guard, does not of course take everyone at their word automatically, so he does not let you in on this basis alone: you could be lying. But it is easy to verify. The guard checks that <tel:+44-161-275-014> is indeed a core guest of the party, and having checked that just calls that number, ask the person if he knows <tel:+1.510.931.5491>. If he answer yes, you are authorized.

With foaf+ssl we can do the same without requiring direct human intervention. By giving your WebId to the guard, he can "call" the WebId using HTTP GET (clicking on the link) and see what information that link returns. If the information returned identifies you (as it does by returning your public key) then we have, as shown previously, confirmed identification. Now if as we are supposing in this example, your URL is not on the list of directly authorized ones, the guard can check the document returned to find if any of your friends are directly authorized. If anyone of them is, he can 'call them' (with an HTTP GET of course) to find out if they claim you as a friend too. So the parallel with the above phone conversation holds very well. (For more detailed description of this example see "Building a web of Trust without Key Signing parties")

This way of linking between documents works because every object in those relations has a identifying URL, and because the documents are published RESTfully. The REST architecture is very strict about names referring to things independent of who uses them or of any previous state between the client and the server. If it were not, different people would be meaning different things with the same URL, which would be very confusing. By making it easy to link between documents we have the basic elements to grow a web of trust.


So how does foaf+ssl and the usual passport like PKI example compare? Here are a few thoughts:

  • foaf+ssl focuses on identity, as OpenId does, but much more RESTfully. Traditional PKI on the other hand also conceives of itself as certifying extra information: name, age, address...
  • In the passport example we pass a document by value, not by reference. The advantage is that that resource can be updated a lot faster than the passport can. One could easily imagine border control situations working like that. All that you would need would be to cite your passport Id to the officer and he could find your record in the government database and check your identity that way (by looking at your picture or checking your fingerprints).
  • To get something similar to the passport example in foaf+ssl, the government would just have to produce its WebIDs. Then the content of the representation returned by that resource would be the governments view on me. (What remains to be done is to find a way to make clear who is speaking for whom - so to distinguish the case when the WebId is my employers and when it is mine)
  • The WebId can much more easily be self created. This makes it easier to say more about oneself than an official source would ever want to be liable for certifying.
  • WebId's can easily be linked to, so other people can relate to you.

this is coming along \*very\* nicely. great work!

Posted by Mike Amundsen on March 03, 2009 at 02:18 PM CET #

Great work Henry really. We are looking forward to supporting FOAF+SSL in Restlet 1.2. See our related RFE:

Best regards,

Posted by Jerome Louvel on March 04, 2009 at 07:52 AM CET #

Post a Comment:
Comments are closed for this entry.



« June 2016