what does foaf+ssl give you that openid does not?

Jason Kolb asked on Twitter "what does foaf+ssl give you that openid does not?". I can make the answer short but not short enough for a tweet. So here are my initial thoughts on this.

  • foaf+ssl gives people and other agents a URL for Identification, just like OpenId does. But in the case of foaf+ssl the user does not need to remember the URL, the browser or keychain does. A login button on a foaf+ssl web site is just a button. No need to enter any identifier. Just click the button. Your browser will then ask you what identity you wish to use. The user does not need to remember the password either (except perhaps that of the keychain if the browser requires it).
  • The foaf+ssl protocol requires minum 1 to 2 network connections. Compare this to the much more complex OpenId sequence diagram. In a world of distributed data where each site can point to data on any other site, this can become really important.
  • the description of foaf+ssl holds on one page. A page is required to list the OpenId specs.
  • foaf+ssl builds on well established standards: REST, RDF, SSL, X509. That is why of course it takes much less space to explain. It does not invent anything new.
  • foaf+ssl is clearly RESTful. You can GET your foaf file, and if you needed update it with PUT. You could create it with POST. No need to reinvent those verbs as OpenId has to do in OpenId Attribute Exchange spec
  • It is easy to add new attributes to the rdf file. It is easy to extend, and to give the extensions meaning. Every attribute is a URI, which when clicked on can give you yet more information about the relation, and participate in the Linked Data cloud. New classes can be created. You can add relations to objects, and those objects themselves can have yet more relations (see my foaf file, and how it relates me to an address, which is related to a country). The complex OpenId attribute exchange spec does not offer any of this.
  • You can reason about the foaf. Well that just comes for free with RDF and OWL. (So you can do this too with OpenId, but you'd have to treat it as a special case of RDF for that to work.)
  • Being simpler, it will be easier to
  • With foaf+ssl you get a web of trust. With OpenId you only get trust indirectly if you trust the OpenId provider. So for example you may trust the information gathered by the foaf+ssl attribute exchange mechanism of someone who has an OpenId provider at the url http://openid.sun.com/, because you trust Sun Microsystems. With foaf+ssl you can get trust of some file on some web server you never heard about because all your friends point to his foaf file.
  • Foaf+ssl is distributed. There is no need for a OpenId provider. You just need a web server, ideally your own at your own domain name. Yes you can run your OpenId server locally too, but then you loose the trust that might have been associated with that domain name. Have you ever wondered why there were so many very large OpenId providers, and not many small ones?
  • Foaf+ssl requires no HTTP redirects: these are problematic on many cell phones I am told, in part often because telecoms proxys get in the way.

OpenId is very well known and widely used now. It has made people aware of the power of a URL for identifying people, and is what helped me find this solution. Furthermore it would be quite easy to create a foaf+openid service as I proposed some time ago, simplifying OpenId in the process. So the two technologies are not incompatible.

More on foaf+ssl on the esw wiki


I don't keep up with the ID stuff anymore since I gave on Smart Cards, turns out strong identification can be easily done with the next generation phones with thumb print readers. What are the attack vectors against OpenID and how does FOAF+SSL compare.

Posted by Rinaldo on December 19, 2008 at 04:47 PM CET #

Hi Rinaldo:

Well foaf+ssl is a lot simpler. So you can look at the sequence diagram to see that any attack vectors on foaf+ssl will also be attack vectors on OpenId, since OpenId uses a lot more of the same: a lot more ssl connections.

foaf+ssl enables a network of trust model to coexist and build upon PKI. PKI is only needed initially to help identify machines, and for message integrity. The social networking layer is best build on a web of trust, ie, people linking to people they trust.

foaf+ssl is still in development, so there is still a lot of discovery to be done. It is past midnight here in Europe, so it is too late for me to go into this right now. In my next post I will look at what still needs to be explored in foaf+ssl. Some things I think need to be looked into are:
- User Interface issues, how well this works with current browsers (it works with all I have tried), but there are questions that need to be resolved for people using public terminals (I have some ideas on this)
- ontologies for Access Control need to be worked on, and perhaps even ways for the user to specify what attributes a web site may be allowed to see. But I have some good ideas on how these can work
- we need to try this out with real services to see how well it works

But the best way to get to solve these problems is to have a few working sites and some users to provide feedback on which features they find most important... So keep tuned. The protocol is easy to implement and so things are moving fast.

Posted by Henry Story on December 19, 2008 at 05:12 PM CET #

PS. I think one could increase security dramatically by using java cards, or crypto usb keys to hold the private keys... Phones with thumb print readers could work very well with this: putting your thumb on the phone would be equivalent to giving a password to your private key, which could then create ssl sessions with the server. These technologies I think would just come and enhance the protocol.

Posted by Henry Story on December 19, 2008 at 05:22 PM CET #

Post a Comment:
Comments are closed for this entry.



« August 2016