The Sun BabelFish Blog

Don't panic !

Main | Next page »

Wednesday Nov 25, 2009

Identity in the Browser, Firefox style

Mozilla's User Interface chief Aza Raskin just put forward some interesting thoughts on what Identity in the Browser could look like for Firefox. As one of the Knights in search of the ~~Golden~~ Holy Grail of distributed Social Networking, he believes to have found it in giving the browser more control of the user's identity.

The mock up picture reproduced below, shows how Firefox, by integrating identity information into the browser, could make it clear as to what persona one is logged into a site as. It would also create a common user interface for allowing one to log in to a site under a specific Identity, as well as allow one to create a new one. Looking at the Weave Identity Account Manager project site one finds that it would also make it easy to generate automatically passwords for each site/identity, to sync one's passwords across devices, as well as to change the passwords for all enabled sites simultaneously if one feared one's computer had fallen in the wrong hands. These are very appealing properties, and the UI is especially telling, so I will reproduce the main picture here:

UI sketches for Identity in the Browser in Firefox

The User Interface

One thing I very strongly support in this project is the way it makes it clear to the user, in a very visible location - the URL bar -, as what identity he is logged in as. Interestingly this is at the same location as the https information bar, when you connect to secure sites. Here is what URL bar looks like when connected securely to LinkedIn:

One enhancement the Firefox team could immediately work on, without inventing a new protocol, would be to reveal in the URL bar the client certificate used when connected to a https://... url. This could be done in a manner very similar to the way proposed by Aza Raskin in the his Weave Account manager prototype pictured above. This would allow the user to

know what HTTPS client cert he was using to connect to a site,
as well as allow him to log out of that site,
change the client certificate used if needed

The last two feature of TLS are currently impossible to use in browsers because of the lack of such a User Interface Handle. This would be a big step to closing the growing Firefox Bug 396441: "Improve SSL client-authentication UI".

From there it would be just a small step, but one that I think would require more investigation, to foaf+ssl enhance the drop down description about both the server and the client with information taken from the WebID. A quick reminder: foaf+ssl works simply by adding a WebID - which is just a URL to identify a foaf:Agent - as the subject alternative name of the X509 certificate in the version 3 extensions, as shown in detail in the one page description of the protocol. The browser could then GET the meaning of that URI, i.e. GET a description of the person, by the simplest of all methods: an HTTP GET request. In the case of the user himself, the browser could use the foaf:depiction of the user, to display a picture of him. In the case of the web site certificate, the browser could GET the server information at its WebId, and display the information placed there. Now if the foaf file is not signed by a CA, then the information given by the remote server about itself, should perhaps be placed on a different background or in some way to distinguish the information in the certificate, from the information gleaned from the WebId. So there are a few issues to work on here, but these just only involve well developed standards - foaf and TLS - and some user interface engineers to get them right. Easier, it seems to me, than inventing a whole protocol - even though it is perhaps every engineers desire to have developed a successful one.

The Synchronization Piece

Notice how foaf+ssl enables synchronization. Any browser can create a public/private key pair using the keygen element, and get a certificate from a WebId server, such as foaf.me. Such a server will then add that public key as an identifier for that WebId to the foaf file. Any browser that has a certificate whose public key matches that published on the server, will be able to authenticate to that server and download all the information it needs from there. This could be information

about the user (name, depiction, address, telephone number, etc, etc)
a link to a resource containing the bookmarks of the user
his online accounts
his preferences

Indeed you can browse all the information foaf.me can glean just from my public foaf file here. You will see my bookmarks taken from delicious, my tweets and photos all collected in the Activity tab. This is just one way to display information about me. A browser could collect all that information to build up a specialized user interface, and so enable synchronization of preferences, bookmarks, and information about me.

The Security Problem

So what problem is the Weave team solving in addition to the problem solved above by foaf+ssl?

The weave synchronization of course works in a similar manner: data is stored on a remote server, and clients fetch and publish information to that server. One thing that is different is that the Weave team wish to store the passwords for each of the user's accounts onto a remote server that is not under the user's control. As a result that information needs to be encrypted. In foaf+ssl only the public key is stored on a remote server, so there is no need to encrypt that information: the private key can remain safely on the client key chain. Of course there is a danger with the simple foaf+ssl server that the owner of the remote service can both see and change the information published remotely depending on who is asking for it. So an unreliable server could add a new public key to the foaf file, and thereby allow a malicious client to authenticate as the user in a number of web sites.

It is to solve this problem that Weave was designed: to be able to publish remotely encrypted information that only the user can understand. The publication piece uses a nearly RESTful API. This allows it to store encrypted content such as passwords, identity information, or indeed any content on a remote server. The user would just need to remember that one password to be able to synchronize his various Identities from one device to another. There is a useful trick that is worth highlighting: each piece of data is encrypted using a symmetric key, which is stored on the server encrypted with a public key. As a result one can give someone access to a piece of data just by publishing the symmetric key encrypted using one of her public key.

Generalization of Weave

To make the above protocol fully RESTful, it needs to follow Roy Fielding's principle that "REST APIs must be hypertext driven". As such this protocol is failing in this respect in forcing a directory layout ahead of time. This could be fixed by creating a simple ontology for the different roles of the elements required in the protocol: such as public keys, symmetric keys, data objects, etc... This would then enable the Linked Data pattern. Allowing each of the pieces of data to be anywhere on the web. Of course nothing would stop the data from being set out the way specified in the current standard. But it immediately opens up a few interesting possibilities. For example if one wanted a group of encrypted resources to be viewed by the same group of people, one would need only one encrypted symmetric key each of those resources could point to, enabling less duplication.

By defining both a way of getting objects, and their encoding, the project is revealing its status as a good prototype. To be a standard, those should be separated. That is I can see a few sperate pieces required here:

An ontology describing the public keys, the symmetric keys, the encrypted contents,...
Mime types for encrypted contents
Ontologies to describe the contents: such as People, bookmarks, etc...

Only (1) and (2) above would be very useful for any number of scenarios. The contents in the encrypted bodies could then be left to be completely general, and applied in many other places. Indeed being able to publish information on a remote untrusted server could be very useful in many different scenarios.

By separating the first two from (3), the Weave project would avoid inventing yet another way to describe a user for example. We already have a large number of those, including foaf, Portable Contacts, vcard, and many many more... I side for data formats being RDF based, as this separates the issues of syntax and semantics. It also allow the descriptions to be extensible, so that people can think of themselves in more complex ways that that which the current developers of Weave have been able to think of. That is certainly going to be important if one is to have a distributed social web.

Publishing files in an encrypted manner remotely does guard one from malicious servers. But it does I think also reduce the usability of the data. Every time one wants to give access to a resource to someone one needs to encrypt the symmetric key for that user. If the user looses his key, one has to re-encrypt that symmetric key. By trusting the server as foaf+ssl does, it can encrypt the information just in time, for the client requesting the information. But well, these are just different usage scenarios. For encrypting password - which we should really no longer need - then certainly the Weave solution is going in the right direction.

The Client Side Password

Finally Weave is going to need to fill out forms automatically for the user. To do this again I would develop a password ontology, and then markup the forms in such a way that the browser can deduce what pieces of information need to go where. It should be a separate effort to decide what syntax to use to markup html. RDFa is one solution, and I hear the HTML5 solution is starting to look reasonable now that they removed the reverse DNS namespace requirement. In any case such a solution can be very generic, and so the Firefox engineers could go with the flow there too.

RDF! You crazy?

I may be, but so is the world. You can get a light triple store that could be embedded in mozilla, that is open source, and that is in C. Talk to the Virtuoso folks. Here is a blog entry on their lite version. My guess is they could make it even liter. KDE is using it....

Posted at 09:34PM Nov 25, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[3]

Thursday Nov 19, 2009

http://openid4.me/ -- OpenId ♥ foaf+ssl

OpenId4.me is the bridge between foaf+ssl and OpenId we have been waiting for.

OpenId and foaf+ssl have a lot in common:

They both allow one to log into a web site without requiring one to divulge a password to that web site
They both allow one to have a global identifier to log in, so that one does not need to create a username for each web site one wants to identify oneself at.
They also allow one to give more information to the site about oneself, automatically, without requiring one to type that information into the site all over again.

OpenId4.me allows a person with a foaf+ssl profile to automatically login to the millions of web sites that enable authentication with OpenId. The really cool thing is that this person never has to set up an OpenId service. OpenId4.me does not even store any information about that person on it's server: it uses all the information in the users foaf profile and authenticates him with foaf+ssl. OpenId4.me does not yet implement attribute exchange I think, but it should be relatively easy to do (depending on how easy it is to hack the initial OpenId code I suppose).

If you have a foaf+ssl cert (get one at foaf.me) and are logging into an openid 2 service, all you need to type in the OpenId box is openid4.me. This will then authenticate you using your foaf+ssl certificate, which works with most existing browsers without change!

If you then want to own your OpenId, then just add a little html to your home page. This is what I placed on http://bblfish.net/:

    <link rel="openid.server" href="http://openid4.me/index.php" />
    <link rel="openid2.provider openid.server" href="http://openid4.me/index.php"/>
    <link rel="meta" type="application/rdf+xml" title="FOAF" href="http://bblfish.net/people/henry/card%23me"/>

And that's it. Having done that you can then in the future change your openid provider very easily. You could even set up your own OpenId4.me server, as it is open source.

More info at OpenId4.me.

Posted at 07:57PM Nov 19, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[3]

Friday Oct 16, 2009

November 2nd: Join the Social Web Camp in Santa Clara

The W3C Social Web Incubator Group is organizing a free Bar Camp in the Santa Clara Sun Campus on November 2nd to foster a wide ranging discussion on the issues required to build the global Social Web.

Imagine a world where everybody could participate easily in a distributed yet secure social web. In such a world every individual will control their own information, and every business could enter into a conversation with customers, researchers, government agencies and partners as easily as they can now start a conversation with someone on Facebook. What is needed to go in the direction of The Internet of Subjects Manifesto? What existing technologies can we build on? What is missing? What could the W3C contribute? What could others do? To participate in the discussion and meet other people with similar interests, and push the discussion further visit the Santa Clara Social Web Camp wiki and

If you are looking for a reason to be in the Bay Area that week, then here are some other events you can combine with coming to the Bar Camp:

The W3C is meeting in Santa Clara for its Technical Plenary that week in Santa Clara.
The following day, the Internet Identity Workshop is taking place in Mountain View until the end of the week. Go there to push the discussion further by meeting up with the OpenId, OAuth, Liberty crowd, which are all technologies that can participate in the development of the Social Web.
You may also want to check out ApacheCon which is also taking place that week.

If you can't come to the west coast at all due to budget cuts, then not all is lost. :-) If you are on the East coast go and participate in the ISWC Building Semantic Web Applications for Government tutorial, and watch my video on The Social Web which I gave at the Free and Open Source Conference this summer. Think: if the government wants to play with Social Networks, it certainly cannot put all its citizens information on Facebook.

Posted at 12:35AM Oct 16, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[1]

Wednesday Oct 07, 2009

Sketch of a RESTful photo Printing service with foaf+ssl

Let us imagine a future where you own your data. It's all on a server you control, under a domain name you own, hosted at home, in your garage, or on some cloud somewhere. Just as your OS gets updates, so all your server software will be updated, and patched automatically. The user interface for installing applications may be as easy as installing an app on the iPhone ( as La Distribution is doing).

A few years back, with one click, you installed a myPhoto service, a distributed version of fotopedia. You have been uploading all your work, social, and personal photos there. These services have become really popular and all your friends are working the same way too. When your friends visit you, they are automatically and seamlessly recognized using foaf+ssl in one click. They can browse the photos you made with them, share interesting tidbits, and more... When you organize a party, you can put up a wiki where friends of your friends can have write access, leave notes as to what they are going to bring, and whether or not they are coming. Similarly your colleagues have access to your calendar schedule, your work documents and your business related photos. Your extended family, defined through a linked data of family relationship (every member of your family just needs to describe their relation to their close family network) can see photos of your family, see the videos of your new born baby, and organize Christmas reunions, as well as tag photos.

One day you wish to print a few photos. So you go to web site we will provisionally call print.com. Print.com is neither a friend of yours, nor a colleague, nor family. It is just a company, and so it gets minimal access to the content on your web server. It can't see your photos, and all it may know of you is a nickname you like to use, and perhaps an icon you like. So how are you going to allow print.com access to the photos you wish to print? This is what I would like to try to sketch a solution for here. It should be very simple, RESTful, and work in a distributed and decentralized environment, where everyone owns and controls their data, and is security conscious.

Before looking at the details of the interactions detailed in the UML Sequence diagram below, let me describe the user experience at a general level.

You go to print.com site after clicking on a link a friend of your suggested on a blog. On the home web page is a button you can click to add your photos.
You click it, and your browser asks you which WebID you wish to use to Identify yourself. You choose your personal ID, as you wish to print some personal photos of yours. Having done that, your are authenticated, and print.com welcomes you using your nicknames and displays your icon on the resulting page.
When you click a button that says "Give Print.com access to the pictures you wish us to print", a new frame is opened on your web site
This frame displays a page from your server, where you are already logged in. The page recognized you and asks if you want to give print.com access to some of your content. It gives you information about print.com's current stock value on NASDAQ, and recent news stories about the company. There is a link to more information, which you don't bother exploring right now.
You agree to give Print.com access, but only for 1 hour.
When your web site asks you which content you want to give it access to, you select the pictures you would like it to have. Your server knows how to do content negotiation, so even though copying each one of the pictures over is feasible, you'd rather give print.com access to the photos directly, and let the two servers negotiate the best representation to use.
Having done that you drag and drop an icon representing the set of photos you chose from this frame to a printing icon on the print.com frame.
Print.com thanks you, shows you icons of the pictures you wish to print, and tells you that the photos will be on their way to your the address of your choosing within 2 hours.

In more detail then we have the following interactions:

Your browser GETs print.com's home page, which returns a page with a "publish my photos" button.
You click the button, which starts the foaf+ssl handshake. The initial ssl connection requests a client certificate, which leads your browser to ask for your WebID in a nice popup as the iPhone can currently do. Print.com then dereferences your WebId in (2a) to verify that the public key in the certificate is indeed correct. Your WebId (Joe's foaf file) contains information about you, your public keys, and a relation to your contact addition service. Perhaps something like the following:
```
:me xxx:contactRegistration </addContact> .
```
Print.com uses this information when it creates the resulting html page to point you to your server.
When you click the "Give Print.com access to the pictures you wish us to print" you are sending a POST form to the <addContact> resource on your server, with the WebId of Print.com <https://nasdaq.com/co/PRNT#co> in the body of the POST. The results of this POST are displayed in a new frame.
Your web server dereferences Print.com, where it gets some information about it from the NASDAQ URL. Your server puts this information together (4a) in the html it returns to you, asking what kind of access you want to give this company, and for how long you wish to give it.
You give print.com access for 1 hour by filling in the forms.
You give access rights to Print.com to your individual pictures using the excellent user interface available to you on your server.
When you drag and drop the resulting icon depicting the collection of the photos accessible to Print.com, onto its "Print" icon in the other frame - which is possible with html5 - your browser sends off a request to the printing server with that URL.
Print.com dereferences that URL which is a collection of photos it now has access to, and which it downloads one by one. Print.com had access to the photos on your server after having been authenticated with its WebId using foaf+ssl. (note: your server did not need to GET print.com's foaf file, as it still had a fresh version in its cache). Print.com builds small icons of your photos, which it puts up on its server, and then links to in the resulting html before showing you the result. You can click on those previews to get an idea what you will get printed.

So all the above requires very little in addition to foaf+ssl. Just one relation, to point to a contact-addition POST endpoint. The rest is just good user interface design.

What do you think? Have I forgotten something obvious here? Is there something that won't work? Comment on this here, or on the foaf-protocols mailing list.

Notes

print.com sequence diagram by Henry Story is licensed under a Creative Commons Attribution 3.0 United States License.
Based on a work at blogs.sun.com.

Posted at 09:15PM Oct 07, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[0]

Wednesday Sep 30, 2009

foaf+ssl in Mozilla's Fennec works!

At yesterday's Bar Camp in La Cantine I discovered that Mozilla's Fennec browser for mobile phones can be run on OSX (download 1.0 alpha 1 here). So I tried it out immediately to see how much of the foaf+ssl login would work with it. The answer is all of it, with just a few easy to fix user experience issues. I really am looking forward to trying the Nokia N810 Internet Tablet for real.

Anyway here are quick snapshots of the user experience.

Getting a certificate

First of all the best news is that the <keygen> tag, now documented in html5 works in Fennec. This means that one can get a client certificate in one click without going through the complex dance I described in "howto get a foaf+ssl certificate to your iPhone".

This is how easy it can be. Go to foaf.me.

After filling out the form, you can create yourself an account on foaf.me:

To make your WebId useful all you need to do is click on the "Claim account with SSL certificate" button -- which could certainly be phrased better -- on the account creation successful page:

Once clicked, your browser will start calculating a new public private key pair, send the public key to the server which will turn it into a certificate, and send that back to your browser, which will then add it to they keychain! All you will see of this whole transaction is:

The Fennec message here is a bit misleading: you should not in fact need to keep a backup copy of your certificate. Foaf+ssl certificates are very cheap to produce. And without a link to the keychain from the popup, most users won't know what is being talked about, or how to keep a backup. Also on a cell phone they may well wonder where to put the backup anyway. So in this case it is wrong, and not that helpful. Much better would be to have a popup say: "Your certificate has been installed. Would you like to see it?" Or something like that. Most people won't care.

Using the certificate

You can then test the foaf+ssl certificate on any number of sites. The foaf.me site has a login button for example that when clicked will get the browser to ask the user to choose a certificate. And, this is where the User Interface choices made by the Mozilla team are just simply embarrassing. Not unusable, but just really bad.

No user ever cares about these details! It is confusing. Do you think users have issues with URLs? Well what do you think they are going to make of the old outdated Distinguished Names?

Just compare this with the User Experience on the iPhone

Quite a few bug/enhancement reports have been reported on this issue on the Mozilla site. See for example Bug 396441 - Improve SSL client-authentication UI, and my other enhancement requests.

Still this user interface issue should be really easy to fix, as it is just a question of making things simpler, ie. of reducing the complexity of their code. And clearly on a cell phone that should be a priority.

Another issue I can see on the Fennec demo browser, is that I could not find a way to remove the certificates.... That would be quite an important functionality too.

But in any case using foaf+ssl on Fennec is the easiest of all cell phone browsers to use currently - and one of the rare ones, if not the only one, that works correctly! So kudos for that! Fennec and the Nokia N810 is the place to look for what a secure life without passwords, without user names, and a global distributed social network can look like on a mobile platform.

Posted at 11:38AM Sep 30, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[6]

Another great Bar Camp in La Cantine

Today, well yesterday (Tuesday) I was at a Bar Camp on Cloud computing, social networks, the Open Stack and Geolocation in the very friendly La Cantine organized by Silicon Sentier in Paris.

La Cantine is a great place to meet lots of people anytime. You can just stop by and drink some coffee while hacking a project on the web. But today with guests from Google, Mozilla, Sun (me and some others) and a very enthusiastic and technical audience the place was full of energy.

As it was a Bar Camp the timetable organized itself. A track on social networks appeared, and so of course I presented foaf+ssl as I had done 10 days before at the Social Web Bar Camp, except that we had to do this without projector this time as we, 20 or so people, were gathered around the bar. So for those who were there who would really like to get a better overview of what this enables, I recommend the following links:

The second video of the blog "FrOSCon: the Free and Open Source Conference in Sankt Augustin, Germany", (best viewed in Firefox 3.5 at present)
The essential foaf.me web site, where one can put together in a few clicks a foaf file and on browsers other than Internet Explorer, get a certificate in one click, (Firefox and Opera are recommended)
The foaf+ssl wiki which contains the links to all the papers and howtos, including the essential mailing list.

This was also the occasion of meeting a lot of very knowledgeable people from Google such as Patrick Chanezon for example, and from the European Mozilla team, such as Tristan Nitot. I was so busy answering questions sadly that I missed quite a lot of the other talks. But I did make a lot of good contacts, that I will now be following up on.

Posted at 01:50AM Sep 30, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[1]

Saturday Jul 25, 2009

Saving Face: The Privacy Architecture of Facebook

In his very interesting thesis draft Saving Face: The Privacy Architecture of Facebook, Chris Peterson, describes through a number of real life stories some very subtle and interesting issues concerning privacy and context that arose during the rapid evolution of the now 250 million member social network.

Perhaps the most revealing of these stories is that of Junior High School student Rachel who broadcast the following distress status message my grandmother just friend requested me. no Facebook, you have gone too far! Chris Peterson develops: Rachel and her grandmother are close. She trusts her grandmother. She confides in her grandmother. She tells her grandmother "private" things. She is certainly closer to her grandmother than many of her Facebook Friends. So what's the big deal? Rachel explains:

Facebook started off as basically an online directory of COLLEGE STUDENTS. I couldn't wait until I had my college email so that I could set up an account of my own, since no other emails would give you access to the site. Now, that was great. One could [meet] classmates online or stay in touch with high school mates [but it] has become a place, no longer for college students, but for anyone. [About] five days ago, the worst possible Facebook scenario occurred, so bizarre that it hadn't even crossed my mind as possible. MY GRANDMOTHER!? How did she get onto facebook?...As my mouse hovered between the accept and decline button, images flashed through my mind of sweet Grandma [seeing] me drinking from an ice luge, tossing ping pong balls into solo cups full of beer, and countless pictures of drunken laughter, eyes half closed. Disgraceful, I know, but these are good memories to me. To her, the picture of my perfectly angelic self, studying hard away at school, would be shattered forever.

The paper is full of legally much more serious stories, but this one is especially revealing as it makes apparent how the flat friendship relation on Facebook does not take into account the context of the relationship. Not all frienships are equal. Most people have only very few friends they can tell everything to. And most often one tells very different stories to different groups of friends. In the physical world we intuitively understand how to behave in different contexts. One behaves one way in church, another in the bar, and yet another way in front of one's teachers, or parents. The context in real life is set by the architecture of the space we are in (something Peter Sloterdijk develops at length in his philosophical trilogy Spheres). The space in which we are speaking and the distance others have to us guides us in what we should say, and how loud we can say it. On Facebook all your friends get to see everything you say.

It turns out that it is possible to create an equivalent contextual space on Facebook using a little know and recently added feature, which allows one to build groups of friends and specify access control policies on posts per group. Chris shows clearly that this by itself is not enough: it requires a much more thorough embedding in the User Interface so that the intuitive feel one has in real life for who hears what and to whom one is speaking is available with the same clarity in the digital space. In the later part of the thesis Chris explores what such a User Interface would need to do to enable a similarly intuitive notion of space to be available.

Applications to the Social Web

One serious element of the privacy architecture of Facebook (and other similar social networks) not covered by this thesis, yet that has a very serious impact in a very large number of domains, is the constant presence of a third party in the room: Facebook itself. Whatever you say on these Social Networks, is visible not only to your group of friends, but also to Facebook itself, and indirectly to its advertisers. Communicating in Facebook puts one then in a similar frame of mind to what people in the middle ages would have been in, when mankind was under the constant, omnipotent and omniscient presence of God who could read every thought, even the most personal. Except that this God is incorporated and has a stock market value fluctuating daily.

For those who wish to escape such an omni-presence yet reap the benefits of online electronic communication, the only solution lies in the development of distributed secure social networks, of a Social Web where every body could own what they say and control who sees it. It turns out that this is possible with semantic web technologies such as foaf and access control mechanisms based on ssl.

One very positive element I take from this thesis is that the minimal technical building blocks for reconstituting a sense of context is the notion of a group and access control of resources. In a the Social Web we should be able to reconstitute this using the foaf:Group class and foaf+ssl for access control. On this basis Chris Peterson's user interface suggestions should be applicable in a distributed social network.

All in all then I found this thesis to be very rewarding and a very interesting read. I recommend it to all people interested in the Social Web.

Posted at 06:32PM Jul 25, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[5]

Friday May 29, 2009

Link Roundup for Friday 29 May 2009

Linked Data is getting a lot of press:

Linking Data and Semantics at O’Reilly is a very interesting article that shows how some developers at O'Reilly Media, the famous computer book publisher, moved from ad hoc XML formats published with complex scripts to RESTful publication, and then found themselves unable but to start using the benefits brought by linked data and the semantic web, thereby simplifying a lot of their data issues. Great progress.
Price Waterhouse Coopers just published a bullish 58 page Technology forecast for the Semantic Web containing a lot of very good articles. download for free here

On a the Social Web front:

I added 5 simple use cases for the Social Web, which foaf+ssl can take care of on the Social Web XG wiki.
Bruno Harbulot tagged release 0.3.1 for the FOAF+SSL java libraries and release maven jars for them, as explained in his e-mail to the list

There is a new project called Interactive Knowledge Stack (IKS), which is a Semantics Based Open Source platform for Small to Medium CMS Providers.

Posted at 08:33PM May 29, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[2]

Thursday May 21, 2009

Identity in the Age of Cloud Computing

The Aspen Institute published a 90 page round table report in April entitled "Identity in the Age of Cloud Computing: The next-generation Internet's impact on business, governance and social interaction" under a generous Creative Commons License. I read the freely available pdf over the last week with interest, as it covers a lot of the topics I am talking on this blog, and gives a good introduction into cloud computing (of which I have not yet written).

The paper is a report by J.D. Lasica of a round table discussion with a number of very experienced people that occurred just before the 2008 presidential election. It included people such as Rod Beckstrom, Director of the National Cyber Security Center of the United States Department of Homeland Security, David Kirkpatrick Senior Editor of Internet and Technology at Forune Magazine, Professor Paul M Romer of Stanford University, known for his work on New Growth Theory, Hal Varian, chief ecoomist at Google, and many more...

The discussion around the table must have been very stimulating. Here is my take on the paper.

Identity

Identity turned out to be the core of the discussion. The abstract summarized this best:

Throughout the sessions personal identity arose as a significant issue. Get it right and many services are enabled and enhanced. The group tended to agree that a user-centric open identity network system is the right approach at this point. It could give everyone the opportunity to manage their own identity, customize it for particular purposes, (i.e., give only so much information to an outsider as is necessary for them to transact with you in the way you need), and make it scalable across the Net. Other ways of looking at it include scaling the social web by allowing the individual to have identity as a kind of service rather than, as Lasica writes, "something done to you by outside interests."

The Cloud

The cloud is a way to abstract everything in the connected web space. It is the way the user thinks of the net. It is nebulous. Where information and services are is not important. This is the experience people have when they read their mail on gmail. They can read their mail from their computer, or from their cell phone, or from their hotel, or from their friends computer. The mail and the web, and their flickr photos, and their delicious bookmarks are all there.

The cloud from the developer's point of view is very similar. He buys computing power or storage on Amazon, Google, GoGrid or the upcoming Sun Cloud. Where exactly the computer is located is not important. If demand for the service he develops grows, he can increase the number of machines to serve that demand. This of course is a great way to quickly and lightly get startups going - no need to get huge financing for a very large number of servers to deal with a hypothetical peak load.

The Social Networks on the cloud also allow people to link up and form virtual and short lived organizations for a task at hand. This again reduces costs enabling the companies to get started for very little money, very quickly, try out an idea. The paper does not say this: venture capital is no longer needed -- good thing too, as it has been serverely reduced by the current recession.

The Cloud and Identity

The cloud is the abstraction where the physical location of things becomes unimportant. What operating systems run the software we use, what computers they run on, where these computers are, all that is abstracted away, virtualized into a puff of smoke.

What is of course still needed is a way to name things and locate them in the cloud. What is needed is a global namespace, and global identifiers. These are indeed known as a Universal Resource Locator (URL). Since everything else is abstracted away, URLs are the only consistent abstraction left to identify resources.

It is therefore just one small step for the panelists to agree that something like foaf+ssl is the solution to identity on the cloud. It is user centric, distributed, permits global social networks, and allows for people to have multiple personalities... Foaf+ssl provides exactly what the panelists are looking for:

open identity would provide the foundation for people to invent and discover a new generation of social signals, advice services, afﬁnity groups, organizations and eventually institutions. Because the identity layer is grounded on the principles of openness and equality, anyone would be able to create social networks, tagging systems, repu- tation systems or identity authentication systems.

Posted at 08:30PM May 21, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[1]

Thursday May 14, 2009

FOAF+SSL: RESTful Authentication for the Social Web

The European Semantic Web Conference (ESWC) will be held in Heraklion on the Island of Crete in Greece from 31 May to 4 June. I will be presenting the paper "FOAF+SSL: RESTful Authentication for the Social Web" which I co-authored with Bruno Harbulot, Ian Jacobi and Mike Jones. Here is the abstract:

We describe a simple protocol for RESTful authentication, using widely deployed technologies such as HTTP, SSL/TLS and Semantic Web vocabularies. This protocol can be used for one-click sign-on to web sites using existing browsers — requiring the user to enter neither an identifier nor a password. Upon this, distributed, open yet secure social networks and applications can be built. After summarizing each of these technologies and how they come together in FOAF+SSL, we describe declaratively the reasoning of a server in its authentication decision. Finally, we compare this protocol to others in the same space.

The paper was accepted by the Trust and Privacy on the Social and Semantic Web track of the ESWC. There are quite a number of interesting papers there.

I have never been to Greece, so I have a feeling I will really enjoy this trip. Hope to see many of you there.

Posted at 11:54PM May 14, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[4]

Tuesday May 12, 2009

A Simple foaf+ssl Identity Provider (IdP)

In order to help people get started with foaf+ssl, we have put together a very simple Identity Provider service (IdP). This removes the need for web services to have to deal with setting up https certificates and changing much to their current web setup. With a few lines of server side code any server can now easily find the WebId of a user, and try out some interesting ideas at little cost. If the experiment is useful, for extra security and reliability a business case can then be made for integrating a full foaf+ssl stack.

The protocol is very much as we outlined in a earlier post entitled "Sketch of a foaf+ssl+openid service". The details of the API are listed directly on the root of the first foaf+ssl IdP serviced, available here: https://foafssl.org/srv/idp. All the Service Provider - that is the consumer of the IdP - needs to do is to add a login button or link to his web page that points to the above IdP with a authreqissuer=$url parameter that points back to a CGI controlled by the Service Provider that can parse the redirect containing the user's WebId. That url comes with a timestamp to avoid replay attacks, and is signed to assure authenticity.

Bruno Harbulot wrote the code and published it under a BSD licence by the University of Manchester where he studies. The code is available on the So(m)mer Subversion repository. You can download it with:

$ svn checkout https://sommer.dev.java.net/svn/sommer/foafssl/trunk foafssl --username guest

and start your own IdP if you want. Please feel free to contribute back improovements, or ping us for missing features.

Update September 14, 2009

The IdP is now RDFa enabled, using Damian Steer's RDFa parser for Jena which I ported to Sesame. The war file can be downloaded directly from the dev.java.net Maven repository. To set up your own IdP use that WAR and follow the foaf+ssl setup instructions for Tomcat. This war may only work for Tomcat 7.

Posted at 12:56PM May 12, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[0]

Tuesday Apr 07, 2009

Sun Initiates Social Web Interest Group

I am very pleased to announce that Sun Microsystems is one of the initiating members of the Social Web Incubator Group launched at the W3C.

Quoting from the Charter:

The mission of the Social Web Incubator Group, part of the Incubator Activity, is to understand the systems and technologies that permit the description and identification of people, groups, organizations, and user-generated content in extensible and privacy-respecting ways.
The topics covered with regards to the emerging Social Web include, but are not limited to: accessibility, internationalization, portability, distributed architecture, privacy, trust, business metrics and practices, user experience, and contextual data. The scope includes issues such as widget platforms (such as OpenSocial, Facebook and W3C Widgets), as well as other user-facing technology, such as OpenID and OAuth, and mobile access to social networking services. The group is concerned also with the extensibility of Social Web descriptive schemas, so that the ability of Web users to describe themselves and their interests is not limited by the imagination of software engineers or Web site creators. Some of these technologies are independent projects, some were standardized at the IETF, W3C or elsewhere, and users of the Web shouldn't have to care. The purpose of this group is to provide a lightweight environment designed to foster and report on collaborations within the Social Web-related industry or outside which may, in due time affect the growth and usability of the Social Web, rather than to create new technology.

I am glad we are supporting this along with these other prestigious players:

This should certainly help create a very interesting forum for discussing what I believe is one of the most important issue on the web today.

Posted at 10:22AM Apr 07, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[4]

Friday Apr 03, 2009

howto get a foaf+ssl certificate to your iPhone

In my previous post I showed that a passwordless distributed social web is already possible on the iPhone. It just requires one to upload a foaf+ssl certificate to it. Here is a relatively easy way to do this. I leave it up to the readers of this blog to build even better ways to do it.

First of course you need to have a foaf+ssl certificate. If you don't have a foaf file, then you may want to first check out foafbuilder to create a foaf file and help you tie your distributed persona on the web together. It would be great if foafbuilder could also create those foaf+ssl certs.... For the moment they don't so the easiest way to get it is using the foafssl.org certificate creation service. That will load the certicicate right in your browser, and help you test it.

Once you have a certificate in your browser - I am assuming Firefox here - you just need to export it to the hard drive. In FF go to Preferences, and click on the advanced tab, and choose the encryption section.

I have a number of foaf+ssl certificates as you can see here. Choose one of them and click the Backup button. This will open another window asking you where you wish to save your certificate. Save it somewhere obvious in pkcs12 format. Make sure the file ends with a .p12 extension. You will also be asked for a password to encrypt your certificate, so it can't be opened in transit. You can use a complex password here as you will only need to remember it once.

Then just mail yourself that .p12 file using an account you can access on the iPhone of course. It is just a matter then of going to your iPhone, and opening your mail. In my mail I added a link to the web service I wanted to use next, to save me typing later.

When you click on the p12 link in your iphone, it will then ask you if you wish to install it. The certificate will most likely not be verified by another party. But that's ok, because you are the person who verified it. It is a certificate about you, and you know yourself better than most other people (except your mama of course).

You are then asked to enter the password you used to encrypt the certificate earlier. Once this is done your certificate will be installed on your iPhone, where it can stay happily for a very long time.

If you wish to have a number of different personalities on the web you can create different foaf profiles of yourself, where you can link different pieces of your web life together. As all detective films show it is very difficult to keep things forever secret. But you can at least keep pieces of your life clearly seperated, to keep nosy people busy.

Posted at 07:19PM Apr 03, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[2]

Global Identity in the iPhone browser

Typing user name/passwords on cell phones is extreemly tedious. Here we show how identification & authentication can be done in two clicks. No URL to type in, no changes to the iPhone, just using bog standard SSL technology tied into a distributed global network of trust, which is known as foaf+ssl.

After having installed a foaf+ssl certificate on my phone (which I will explain how to do in my next post), I directed Safari to foaf.me, which is a foaf+ssl enabled web site. This brought up the following screen:

This is a non personalised page. In the top right is a simple foaf+ssl login button. This site was not designed for the iPhone, or it would have been a lot more prominent. (This is easy to change for foaf.me of course). So I the zoomed onto the login link as shown in the following snapshot. Remember that I don't have an account on foaf.me. This could be the first time ever I go there. But nevertheless I can sign up: just click that link.

So clicking on this foaf+ssl enabled link brings up the following window in Safari. Safari warns me first that the site requires a certificate. The link I clicked on sent me to a page that is requesting my details.

certificate warning

As I do in fact want to login, I click the continue button. The iPhone then presents me with an identity selector, asking me which of my two certificates I want to use to log in:

Having selected the second one, the certificate containing my bblfish.net WebId is sent to the server, which authenticates me. The information from my foaf file is then used to personalise my foaf.me experience. Here foaf.me gives me a nice human readable view of my foaf file. I can even explore my social network right there and then, by clicking on the links to my friends. Again, this will work even if you never did go to foaf.me before. All you need is of course a well filled out foaf file, which services such as foafbuilder.qdos.com are making very easy to do. Anyway, here is the foaf.me personalised web page. It really knows a lot about me after just 2 clicks!

The foaf.me site currently has another tab, showing my activity stream of all the chats I have on the web, which it can piece together since I linked all my accounts together in my foaf file, as I explained in the post "Personalising my Blog" a few months ago.

Other web sites could use this information very differently. My web server itself may also decide to show selected information to selected servers... Implementing this is it turns out quite easy. More on that on this blog and on the foaf-protocols mailing list.

Posted at 06:14PM Apr 03, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[3]

Friday Mar 20, 2009

Join the foaf+ssl community and get OpenId for free

Toby Inkster today was the first to put up an OpenId authentication service, that uses foaf+ssl certificates as credentials. This means that anyone with a foaf+ssl certificate can now log in not just to all the fun foaf+ssl services that are popping up, but also to the 100's of thousand of other services out there that are using OpenId - making it so much more valuable.

The OpenId service is written in Perl and requires less that 100 lines of code (see source).

From a user's perspective this is what happens, once everything is set up.

Go to an OpenId enabled service - I tried DZone and Identi.ca.
Enter your OpenId - I used http://bblfish.net/ - in the provided field. And click return.
Your browser will open a client cert popup asking which certificate you want to send - (you should set your browser up to ask you). Choose your foaf+ssl enabled cert. Press enter.
You will be logged in.

This has a few advantages:

You no longer have to remember a password for the OpenId server. Your browser keeps that information.
The OpenId server does not know your password either.
You never had to tell the OpenId Server anything about yourself. All the information is available in your foaf file. And you could protect parts of your foaf file with foaf+ssl so that the OpenId service need know just the public stuff. You could then give special access to the service you are logging into to see protected parts.
It is very easy to change the OpenId Server: just change the openid.server line in your OpenId page. Since the server maintains no state about you, this is easy to do: you won't have to create a new account, specify your name, address, ... remember another password, etc...
No need for attribute exchange - though the server could easily be enhanced to enable it - since the attributes are all in the foaf file, linked to from the OpenId page. See my 2007 post: Foaf and Openid.
It takes one less request to do this than in usual OpenId implementations, as the login step is removed. (this is replaced it is true by one more connection from the OpenId server to the foaf file. But this could be cached.)

It is very easy to get going - especially given that we are dealing with the first release software! Here are the steps:

First of course get yourself a foaf+ssl certificate in your browser, and a correspondingly foaf id. There are a number of services listed on the foaf+ssl wiki. Two solutions:
- You can use the easy to use foafssl.org certificate creation service, but you'll need the foaf file to then point back to the OnlineAccount just created. This would require adding the following triple in geek mode to your foaf file, in order to help verify your identity claim:
```
<http://you.com/foaf#me> <http://xmlns.com/foaf/0.1/holdsAccount> <http://test.foafssl.org/certs/0xx.rdf#accnt>.
```
- Or you can follow the even more geeky instructions from my original blog to create yourself a certificate.
We need to work on making the user experience much easier of course. This here is still just a proof of concept.
Next add a link from your OpenId page to the foaf server, and to your foaf file. A good choice for your OpenId page is your home page. Add the following in the <head>...</head> section of your html. <link rel="openid.server" href="https://ophelia.g5n.co.uk:10443/openid/provider.cgi?webid=http%3A%2F%2Fbblfish.net%2Fpeople%2Fhenry%2Fcard%23me" title="FOAF+SSL OpenId Server"/> <link rel="meta" title="foaf" href="http://bblfish.net/people/henry/card" type="application/rdf+xml" /> You can see an example in the source of my home page at http://bblfish.net/. The pattern to follow for the href attribute is https://ophelia.g5n.co.uk:10443/openid/provider.cgi?webid=W where you replace W by the URL encoded value of your WebId. (You can use an online service such as this devshed one to do the encoding). The encoded WebId helps the OpenId authentication service verify that the person logging in there is really you - the person referred to by your webid. You should also point to your foaf file using the meta link, so that other services on the web can find this information easily.
You need to add a foaf:openid relation from your WebId to your OpenId page in your foaf file. This is so that the OpenId server can identify you in your foaf file. I added the following triple in my foaf.
```
<http://bblfish.net/people/henry/card#me> <http://xmlns.com/foaf/0.1/openid> <http://bblfish.net/> .
```
Which can take a number of different forms in rdf/xml of course.

That is it. This could easily be automated by foaf service providers. I'll update it as soon as we have some easier means of doing this.

Posted at 03:37PM Mar 20, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[3]

Tuesday Mar 03, 2009

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!

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.

Conclusion

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.

Posted at 08:23PM Mar 03, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[2]

Thursday Feb 12, 2009

sketch of a foaf+ssl+openid service

Discussing foaf+ssl with Melvin Carvalho he pointed out that we need a service to help non https enabled servers to participate in our distributed open secure social network. This discussion led me to sketch out the following simple protocol, where I make use of parts of the OpenId protocol at key points. This results in something that does what OpenId does, but without the need for users to remember their URL, and so without many of the problems that plague that protocol. And all this with minimal protocol invention.

So first here is the UML sequence diagram for what I am calling here tentatively foaf+ssl+openid.

First Romeo arrives on a public page with a login button.
- On an OpenId server there would be a field for the user to enter their ID, with foaf+ssl this is not needed. So we have a simple login button.
- That button's action attribute points to some foaf+ssl+openid service that server trusts (it is therefore an https URL). It can be any such service. In OpenId the Id entered by the user points the server to a web page that points the service to an openid server the user (Romeo here) trusts. All of this is no longer needed with this protocol. The html for the login button can be static.
- The URL has to encode information for the foaf+ssl service to know who to contact back. One should use exactly the same URL format here as OpenId does. (minus the need to encode User's URL since that will be in the X509 certificate)
When Romeo clicks the login button he opens an https request to the foaf+ssl+openid service.

The foaf+ssl+openid service on opening the connection asks for the client's certificate after sending its own. This would contain

The User's Public key

      Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:b6:bd:6c:e1:a5:ef:51:aa:a6:97:52:c6:af:2e:
                    71:94:8a:b6:da:9e:5a:5f:08:6d:ba:75:48:d8:b8:
                    01:50:d3:92:11:7d:90:13:89:48:06:2e:ec:6e:cb:
                    57:45:a4:54:91:ee:a0:3a:46:b0:a1:c2:e6:32:4d:
                    54:14:4f:42:cd:aa:05:ca:39:93:9e:b9:73:08:6c:
                    fe:dc:8e:31:64:1c:f7:f2:9a:bc:58:31:0d:cb:8e:
                    56:d9:e6:da:e2:23:3a:31:71:67:74:d1:eb:32:ce:
                    d1:52:08:4c:fb:86:0f:b8:cb:52:98:a3:c0:27:01:
                    45:c5:d8:78:f0:7f:64:17:af
                Exponent: 65537 (0x10001)

The Subject's Alternative Name WebId

        X509v3 extensions:
           ...
           X509v3 Subject Alternative Name: 
                           URI:http://romeo.net/#romeo

The ability for browsers to do this is all part of the standard TLS handshake available in most browsers for a few generations.

The server looks in the client certificate for the Subject Alternative Name in the SSLv3 extensions, and fetches the foaf file at that URL
The service then does a simple match on the information from the foaf file and the information from the certificate. If they match the foaf+ssl+openid service knows that the user <http://romeo.net/#rome> controls <http://romeo.net/> web page. This is enough for simple authentication. (For more on this see Creating a Web of Trust withouth Key Signing Parties )
Depending on the result, the foaf+ssl+openid service can return a redirect with an authentication token to the original service Romeo wanted to log into. This can also be done using the patterns developed in the OpenId community.
The browser then redirects to the Original service.
The service now has Romeo's URL. But to avoid a man in the middle attack, or replay attacks it follows the OpenId protocol and does a little check with its service on a token sent to it in the redirect in step 6.
((Perhaps this step could be avoided if the foaf+ssl+openid service made public it's public key, and encrypted some token sent to by the client to the server. But we could just stick closely to the well trodden OpenId path and just reuse their libraries.))
Having verified the identity of the user, the service could optionally GET the user's foaf file, for public information about him.
Or it could check the relation that user has to it's trusted graph of friends,
and return a presonalised resource

One could also imagine a foaf+ssl+openid server enabled with attribute exchange functionality, which it could get access to simply by reading the foaf file.

I am not sure how much of a problem it really is for servers not to have SSL access. But this could easily fill that gap.

Posted at 06:35PM Feb 12, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[1]

creating a foaf+ssl cert in a few clicks

In a previous blog I showed how to create a foaf+ssl cert manually. I have now put up a simple test server where you can do the same in a few clicks.

The test.foaf-ssl.org/cert service will add a certificate to your browser securely, and create a local acount to which your certificate is pointing. This account will itself point to your Web Id. An account in this scheme is nothing more than an RDF file, such as the ones listed in the certs directory. You can then login in one click, without needing to remember a URL to other foaf+ssl services on the web. There are a few and growing number of prototype implementations listed on the foaf+ssl wiki.

All that remains to be done now is to create more interesting and valuable services using the distributed social networks and foaf+ssl. For some ideas on things to do consult the foaf+ssl Use Cases. The foaf protocols mailing list is a great place to get help on implementations and discuss ideas.

The server is written using Wicket and deployed on a GlassFish Application Server. The code is open source under a BSD licence. Hackers welcome!

Posted at 11:59AM Feb 12, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[3]

Saturday Jan 17, 2009

foaf+ssl: creating a web of trust without key signing parties

The concept of a Web of Trust is most closely associated with Phil Zimmerman and PGP. The basic idea is that by signing each other's keys, usually at things like key signing parties, people could grow the network of keys they trusted to sign or encrypt documents such as email, sign legal documents, etc... The distributed system of trust feels right, but the idea never really took off - even though the keysigning parties must have been fun - probably because they still required physical presence. Another problem with the PGP web of trust, is that the signers of your key, or your signature on someone else's key will forever be published on one of the many key servers, making it close to impossible to revoke an association once published.

In foaf+ssl we are also using a Web of Trust mechanism, but as I will show here, this does not require key signing. It should therefore be able to grow much faster, and hopefully give us the same benefits. The friendship relations are furthermore not embedded in the signature. They can be made to be only visible to those people you wish to make it visible to, and these can be changed at any moment.

I wrote this rather long post as I was starting to answer a question John Kemp asked in the comments of my duck rabbit post on the topic of authorization in foaf+ssl. As I found the answer was getting long and longer, I decided this justified its own blog entry. So I published it here instead.

John Asked a question that forced me to detail how the trust mechanism in foaf+ssl works. Here it is:

The problem (I think) with how you use the certs [in foaf+ssl] though is that the real trust (if Juliet does not know Romeo a priori) is that Juliet's friends know Romeo, and when I say "know", I don't mean that in any cryptographic sense (Juliet's friends haven't signed Romeo's key/key fingerprint for example). Why wouldn't it then be enough for Juliet to base her trust on the appearance of Romeo's OpenID in her friends' FOAF files, for example?

I like the web of trust model, but in order for there to be verifiable trust based on certs/keys, don't you also need key/cert/fingerprint signing parties?

Since this is going to require thinking carefully about the foaf+ssl protocol, we may as well have its UML sequence diagram in front of our eyes. Here it is:

Remember that at stage 5 Juliet's server knows only the following about <https://romeo.net/#romeo>

The Agent connecting via ssl has access to the private key that matches the public key sent in the cert (because otherwise he could not have signed the cert, and could not have established the ssl connection)
The Agent wishes to be identified as "https://romeo.net/#romeo"
Dereferencing the information resource <https://romeo.net/#romeo> returns the document <https://romeo.net/> which states that anyone who can proove to have the private key for the given public key is <https://romeo.net/#romeo>

Juliet's server can then conclude that the Agent making the request is indeed <https://romeo.net/#romeo> - whoever or whatever that is. Juliet's server can be as confident in this fact as the cryptography algorithms allow her to, which is pretty good.

So at this point we have something between identification and authentication, I am not sure.

When Basing Trust on OpenId does not work

Other statements returned by <https://romeo.net/> are extra claims and are as trustworthy as statements made by <https://romeo.net/#romeo>. They may just by themselves solve some really interesting puzzles for Juliet's server that by could make it trust <https://romeo.net/#romeo> more than anyone else it ever met -- but web servers of this intelligence are unlike any I have yet seen.

More realistically, the question for Juliet's server is whether it should authorize access to the protected resource. If Juliet's friends identify Romeo indirectly via his OpenId, and using that only, with something like the following relations in N3

  @prefix foaf: <http://xmlns.com/foaf/0.1/> .
  @prefix : <#> .

  :anne foaf:knows _:bN .
  _:bN foaf:name "Romeo";
       foaf:openid <https://openid.sun.com/romeo> .

and Romeo publishes a relation he has to an OpenId too such as

  @prefix : <#> .  

  :romeo foaf:openid <https://openid.sun.com/openid> .

Then if Juliet's server wants to motivate access to the protected resource it would need to believe the following

  :anne foaf:knows :romeo .

which appears nowhere. It would have to be inferred from a statement such as

  _:bN = :romeo .

This can indeed be inferred from the statements in Romeo's file giving his OpenId, and the statement in :anne's file stating the relation of the blank node _:bN to the same OpenID, since foaf:openid is an inverse functional property. But what is the confidence Juliet's server can have in that? Well Juliet's server can be as confident of that as she is of the assertion made by <https://romeo.net/#romeo> that his openid is <https://openid.sun.com/romeo>. This can hardly be said to count as confirmatory evidence. If Juliet's server thinks like that, it might as well make the resource public. For it would be the equivalent of a prison officer freeing a prisoner solely on the basis of the claim that he is himself an officer.

Who should one trust?

On the other hand if Juliet's friend :anne had claimed that

   :anne foaf:knows <https://romeo.net/#romeo> .

then Juliet's server would have had the piece of information needed to authorize access to the protected resource, because that information came from a trusted party.

So in summary, when Juliet's server is looking to evaluate the trust it can have in :romeo it should not ask :romeo himself . It should ask other people in the social networks she trusts. So the graphs it needs to search is everything except what is said by :romeo . Juliet's server can go on the following:

that it is speaking to <https://romeo.net/#romeo>
what Juliet believes
what Juliet believes of what her friends claim
the consequences of the claims it is able to or willing to calculate

Now the OpenId can in fact come in useful, but not directly as may have been hoped initially. Imagine that Juliet now has another resource that she only gives access to, to people known by two of her friends. If only one of her friends, say :jane makes the assertion that

  :romeo foaf:openid <https://openid.sun.com/romeo> .

but all other of her friends refer to :romeo indirectly, then her web server could use that information with the statement made by :anne to deduce that indeed at least two of Juliet's friends know :romeo.

The value of information published by Romeo

Now is it absolutely true that Juliet's server can do nothing with the information returned by the document <https://romeo.net/>? Not at all! It is just that it has to be used in an exploratory manner. Imagine a third resource that is accessible to friends of friends of Juliet's friends. We could imagine that <https://romeo.net/> had returned a list of friends for :romeo, perhaps with the following relations:

:romeo foaf:knows <https://jack.name/#jack>, <https://john.name/#john>, <https://duffy.duck/p/#dd> .

Juliet's server could decide to dereference (HTTP GET) both <https://jack.name/#jack> and <https://john.name/#john> because they were known by her friends and see if any of those claimed to know <https://romeo.net/#romeo>.

Special case: when the OpenId published by Romeo is trustworthy

This highlights then a special case where the OpenId published by Romeo can work correctly out of the box. This is when his OpenId is his foaf file. Ie when Romeo publishes something like:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<http://romeo.net/> a foaf:PersonalProfileDocument;
            foaf:primaryTopic <http://romeo.net/#romeo> .

<http://romeo.net/#romeo> a foaf:Person;
            foaf:openid <http://romeo.net/> .

Here the foaf personal profile document is the same as the one returned when dereferencing Romeo's web id <http://romeo.net/#romeo>. It is returned in the same representation as the statements we are trusting on :romeo's public key, and assigning this relation to the same person. Since an OpenId is a resource controlled by the person whose openid it is, and since we believe that this resource is now controlled by <http://romeo.net/#romeo> I think we can safely say that Juliet's server knows :romeo's OpenId in this particular case too.

There is another case where the OpenId published by :romeo could work, even when the OpenId is not the same as the foaf:PersonalProfileDocument, but in this case it would require some verification. So let us get back to the situatuon described earlier in this post where Romeo's WebID claims that

  :romeo foaf:openid <https://openid.sun.com/romeo> .

For Juliet to believe this she would have to verify that http://romeo.net/#romeo controls https://openid.sun.com/romeo. This could be done very simply if Romeo has that OpenId page link back in some way to his foaf ID. Perhaps, as I suggested in "Foaf and Openid" this could be done simply by adding the following to the header of the OpenId page:

<link rel="meta" type="application/rdf+xml" title="FOAF" href="http://romeo.net/"/>

Juliet's web server would then be able to fetch the OpenId page, and having found the above link back to the :romeo's Personal Profile Document, it would be able to conclude that he controlled https://openid.sun.com/romeo, and so that it is a legitimate OpenId for him. With foaf+ssl Juliet's server can verify an OpenId with only one extra connection!

Web of Trust and Key Signing

All the above clearly shows that you can create a web of trust without key signing parties. Parties are nice, but requiring Key Signing parties is something that has seriously dampened the adoption of PGP and the web of trust. By just dragging and droping a URL from a web page, an email, another application into your foaf Address Book (be it web based or not), you can grow your web of trust much faster than Keysigning can. Furthermore you can change your public key when you no longer need it, loose it or whatever without needing to re-sign all your keys. This therefore adds to the security of your web of trust.

This is not to say that foaf+ssl is incompatible with key signing, btw. and it may be interesting to find out where this remains useful.

Posted at 03:53PM Jan 17, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[8]

Friday Jan 16, 2009

The W3C Workshop on the Future of Social Networking Position Papers

I am in Barcelona, Spain (the country of Dali) for the W3C Workshop on the Future of Social Networking. To prepare for this I decided to read through the 75 position papers. This is the conference I have been the best prepared for ever. It really changes the way I can interact with other attendees. :-)

I wrote down a few notes on most paper I read through, to help me remember what I read. This took me close to a week, a good part of which I spent trying to track down the authors on the web, find their pictures, familiarise myself with their work, and fill out my Address Book. Anything I could do to help me find as many connections as possible to help me remember the work. I used delicious to save some subjective notes, which can be found on under the w3csn tag. I was going to publish this on Wednesday, but had not quite finished reading through all the papers. I got back to my hotel this evening to find that Libby Miller, who co-authored the foaf ontology, had beat me to it with the extend and quality of her reviews which she published in a two parts:

Part one covers papers 1 to 42
Part two covers paper 43 to 72 and the three late ones

Amazing work Libby!

70 papers is more than most people can afford to read. If I were to recommend just a handful of papers that stand out in my mind for now these would be:

Paper 36 by Ching-man Au Yeung, Laria Liccardi, Kanghao Lu, Oshani Seneviratne and Tim Berners Lee wrote the must read paper entitled "Decentralization: The Future of Online Social Networking". I completely agree with this outlook. It also mentions my foaf+ssl position paper, which of course gives it full marks :-) I would use "distribution" perhaps over "decentralisation", or some word that better suggests that the social network should be able to be as much of a peer to peer system as the web itself.

"Leveraging Web 2.0 Communities in Professional Organisations" really prooves why we need distributed social networks. The paper focuses on the problem faced by Emergency Response organisation. Social Networks can massively improove the effectiveness of such responses, as some recent catastrophes have shown. But ER teams just cannot expect everyone they deal with to be part of just one social network silo. They need to get help from anywhere it can come from. From professional ER teams, from people wherever they are, from infromation wherever it finds itself. Teams need to be formed ad hoc, on the spot. Not all data can be made public. Distributed Open Secure Social Networks are what is needed in such situations. Perhaps the foaf+ssl proposal (wiki page) can help to make this a reality.

In "Social networking across devices: opportunity and risk for the disabled and older community", Henni Swan explains how much social networking information could be put to use to help make better user interface for the disabled. Surprisingly enough none of the web sites, so taken by web 2.0 technologies, seem to put any serious, effort in this space. Aparently though this can be done with web 2.0 technologies, as Henny explains in her blog. The semantic Web could help even further I suggested to her at her talk today, by splitting the data from the user interface. Specialised browsers for the disabled could adapt the information for their needs, making it easy for them to navigate the graph.

"Trust and Privacy on the Social Web" starts the discussion in this very important space. If there are to be distributed social networks, they have to be secure, and the privacy and trust issues need to be looked at carefully.

On a lighter note, Peter Ferne's very entertaining paper "Collaborative Filtering and Social Capital" comes with a lot of great links and is a pleasure to read. Did you know about the Whuffie Index or CELEBDAQ? Find out here.

Many of the telecoms papers, of which Telefonica's "The social network behind telecom networks" reveal the elephant in the room that nobody saw in social networking: the telecoms. Who has the most information about everyone's social network? What could they do with this information? How may people have phones, compared to internet access? Something to think about.

Nokia's position paper can then be seen in a different light. How can handset manufacturers help put to use the social networking and location information contemporay devices are able to access? The Address Book in cell phones is the most important application in a telephone. But do people want to only connect to other Nokia users? This has to be another reason for distributed social networks.

I will blog about other posts as the occasion presents itself in future blogs. This is enough for now. I have to get up early and be awake for tomorrow's talks which start at 8:30 am.

In the mean time you can follow a lively discussion of the ongoing conference on twitter under the w3csn tag.

Posted at 12:52AM Jan 16, 2009 [permalink/trackback] by Henry Story in SemWeb | Comments[8]