Wednesday Jan 13, 2010

Faviki: social bookmarking for 2010

faviki logo

Faviki is simply put the next generation social bookmarking service. "A bookmarking service? You must be kidding?!" I can hear you say in worried exasperation. "How can one innovate in that space?" Not only is it possible to innovate here, let me explain why I moved all my bookmarks from delicious over to faviki.

Like delicious, digg, twitter and others... Faviki uses crowd sourcing to allow one to share interesting web pages one has found, stay up to date on a specific topic of interest, and keep one's bookmarks synchronized across computers. So there is nothing new at that level. If you know del.icio.us, you won't be disoriented.

What is new is that instead of this being one crowd sourced application, it is in fact two. It builds on wikipedia to help you tag your content intelligently with concepts taken from dbpedia. Instead of tagging with strings the meaning of which you only understand at that time, you can have tags that make sense, backed by a real evolving encyclopedia. Sounds simple? Don't be deceived: there is a huge potential in this.

Let us start with the basics: What is tagging for? It is here to help us find information again, to categorize our resources into groups so that we can find them again in the rapidly increasing information space. I now have close to ten years of bookmarks saved away. As a result I can no longer remember what strings I used previously to tag certain categories of resources. Was it "hadopi", "paranoia", "social web", "socialweb", "web", "security", "politics", "zensursula", "bigbrother", "1984", ... If I tag a document about a city should I tag it "Munich", "München", "capital", "Bavaria", "Germany", "town", "agglomeration", "urbanism", "living", ...? As time passed I found it necessary to add more and more tags to my bookmarks, hoping that I would be able to find a resource again in the future by accidentally choosing one of those tags. But clearly that is not the solution. Any of those tags could furthermore be used very differently by other people on delicious. Crowd sourcing only partially works, because there is no clear understanding on what is meant by a tag, and there is no space to discuss that. Is "bank" the bank of a river, or the bank you put money in? Wikipedia has a disambiguation page for this, which took some time to put together. No such mechanism exists on delicious.

Faviki neatly solves this problem by using the work done by another crowd sourced application, and allowing you to tag your entries with concepts taken from there. Before you tag a page, Faviki finds some possible dbpedia concepts that could fit the content of the page to tag. When you then choose the tags, the definition from wikipedia is made visible so that you can choose which meaning of the tag you want to use. Finally when you tag, you don't tag with a string, but with a URI: the DBPedia URI for that concept. Now you can always go back and check the detailed meaning of your tags.

But that is just the beginning of the neatness of this system. Imagine you tag a page with http://dbpedia.org/resource/Munich (the user does not see this URL of course!). Then by using the growing linked data cloud Faviki or other services will be able to start doing some very interesting inferencing on this data. So since the above resource is known to be a town, a capital, to be in Germany which is in Europe, to have more than half a million inhabitants, to be along a certain river, that contains certain museums, to have different names in a number of other languages, to be related in certain ways to certain famous people (such as the current Pope)... it will be possible to improve the service to allow you to search for things in a much more generic way: you could search by asking Faviki for resources that were tagged with some European Town and the concept Art. If you are searching for "München" Faviki will be able to enlarge the search to Munich, since they will be known to be tags for the same city...

I will leave it as an exercise to the reader to think about other interesting ways to use this structured information to make finding resources easier. Here is an image of the state of the linked data cloud 6 months ago to stimulate your thinking :-)

.

But think about it the other way now. Not only are you helping your future self find information bookmarked semantically - let's use the term now - you are also making that information clearly available to wikipedia editors in the future. Consider for example the article "Lateralization of Brain Function" on wikipedia. The Faviki page on that subject is going to be a really interesting place to look to find good articles on the subject appearing on the web. So with Faviki you don't have to work directly on wikipedia to participate. You just need to tag your resources carefully!

Finally I am particularly pleased by Faviki, because it is exactly the service I described on this blog 3 years ago in my post Search, Tagging and Wikis, at the time when the folksonomy meme was in full swing, threatening according to it's fiercest proponents to put the semantic web enterprise into the dustbin of history.

Try out Faviki, and see who makes more sense.

Some further links:

Tuesday Jan 05, 2010

MISC 2010 and the Internet of Subjects

The International Conference on Mobility, Individualisation, Socialisation and Connectivity (MISC 2010) will be taking place in London from Jan 20 to 23 under the rallying cry "Personal Data It's Ours!". It will cover a very large number of topics in the space of Identity, the Social Web, Privacy and Data Ownership, (see the Agenda). I will be presenting on the developments of the Secure Social Web with foaf+ssl.

The conference will also be the launch pad for the Internet of Subjects foundation, whose manifesto starts with the following lines (full version)

The place digital technologies have now dwelled in our lives is leading to an ever-increasing flow of personal data circulating over the Internet. The current difficulties experienced in personal data management, like trust and privacy, are the revealing symptoms of a growing contradiction between an architecture that was primarily designed to manage documents, with the growing expectations of individuals of a more person-centric web. This contradiction will not be resolved by adding a simple patch to the current architecture; a second order change, similar to Copernican revolution, is required to move from a document-centric to a p erson-centric Internet, and create the conditions for a more balanced and mature relationship between individuals and organisations.

I completely sympathise with the feeling expressed by this message. But just as the Copernican revolution did not require an actual change in the movement of the planets - they have been turning around the Sun quite happily for billions of years - but 'only' required a change in how the humanity thought about the movement of the planets, so Web architecture as it currently stands, is perfectly adequate for an Internet of Subjects. It has been designed like that right from the beginning. Tim Berners Lee in his 1994 Plenary at the First International World Wide Web Conference, presented a Paper "W3 future directions" where he showed how from the flat world of documents as shown here

one could move to a world of objects described by those documents as shown here

This is what led to the development of the semantic web, and to technologies such as foaf that since 2000 have allowed us to build distributed Social Networks, and foaf+ssl that are allowing us now to secure them. Using the semantic web then to describe the authors of the documents and hence turn the web of objects into a web of subjects making statements about objects, does not require much technological innovation: it's built into the semweb architecture.

Still to someone who does not know this - the conference as well as the Manifesto are aimed at people who don't - their feeling will be that something is fundamentally wrong with web architecture. This is indeed the feeling the pre Copernican astronomers would have had as their models became more and more complicated to accommodate the always increasing amount of information they gathered about the stars. What should have been simple and beautiful, revealing the mind of God, must have seemed more and more confusing. Until one day, the way the world looked, suddenly changed...

Sunday Nov 29, 2009

Web Finger proposals overview

If all you had was an email address, would it not be nice to be able to have a mechanism to find someone's home page or OpenId from it? Two proposals have been put forward to show how this could be done. I will look at them and add a sketch of my own that hopefully should lead us to a solution that takes the best of both proposals.

The WebFinger GoogleCode page explains what webfinger is very well:

Back in the day you could, given somebody's UNIX account (email address), type
$ finger email@example.com 
and get some information about that person, whatever they wanted to share: perhaps their office location, phone number, URL, current activities, etc.

The new ideas generalize this to the web, by following a very simple insight: If you have an email address like henry.story@sun.com, then the owner of sun.com is responsible for managing the email. That is the same organization responsible for managing the web site http://sun.com. So all that is needed is some machine readable pointer from http://sun.com/ to a lookup giving more information about owner of the email address. That's it!

The WebFinger proposal

The WebFinger proposed solution showed the way so I will start from here. It is not too complicated, at least as described by John Panzer's "Personal Web Discovery" post.

John suggests that there should be a convention that servers have a file in the /host-meta root location of the HTTP server to describe metadata about the site. (This seems to me to break web architecture. But never mind: the resource http://sun.com/ can have a link to some file that describes a mapping from email ids to information about it.) The WebFinger solution is to have that resource be in a new application/host-meta file format. (not xml btw). This would have mapping of the form

Link-Pattern: <http://meta.sun.com/?q={%uri}>; 
    rel="describedby";type="application/xrd+xml"
So if you wanted to find out about me, you'd be able to do a simple HTTP GET request on http://meta.sun.com/?q=henry.story@sun.com, which will return a representation in another new application/xrd+xml format about the user.

The idea is really good, but it has three more or less important flaws:

  • It seems to require by convention all web sites to set up a /host-meta location on their web servers. Making such a global requirement seems a bit strong, and does not in my opinion follow web architecture. It is not up to a spec to describe the meaning of URIs, especially those belonging to other people.
  • It seems to require a non xml application/host-meta format
  • It creates yet another file format to describe resources the application/xrd+xml. It is better to describe resources at a semantic level using the Resouces Description Framework, and not enter the format battle zone. To describe people there is already the widely known friend of a friend ontology, which can be clearly extended by anyone. Luckily it would be easy for the XRD format to participate in this, by simply creating a GRDDL mapping to the semantics.

All these new format creation's are a real pain. They require new parsers, testing of the spec, mapping to semantics, etc... There is no reason to do this anymore, it is a solved problem.

But lots of kudos for the good idea!

The FingerPoint proposal

Toby Inkster, co inventor of foaf+ssl, authored the fingerpoint proposal, which avoids the problems outlined above.

Fingerpoint defines one useful relation sparql:fingerpoint relation (available at the namespace of the relation of course, as all good linked data should), and is defined as

sparql:fingerpoint
	a owl:ObjectProperty ;
	rdfs:label "fingerpoint" ;
	rdfs:comment """A link from a Root Document to an Endpoint Document 
                        capable of returning information about people having 
                        e-mail addresses at the associated domain.""" ;
	rdfs:subPropertyOf sparql:endpoint ;
	rdfs:domain sparql:RootDocument .
It is then possible to have the root page link to a SPARQL endpoint that can be used to query very flexibily for information. Because the link is defined semantically there are a number of ways to point to the sparql endpoint:
  • Using the up and coming HTTP-Link HTTP header,
  • Using the well tried html <link> element.
  • Using RDFa embedded in the html of the page
  • By having the home page return any other represenation that may be popular or not, such as rdf/xml, N3, or XRD...
Toby does not mention those last two options in his spec, but the beauty of defining things semantically is that one is open to such possibilities from the start.

So Toby gets more power as the WebFinger proposal, by only inventing 1 new relation! All the rest is already defined by existing standards.

The only problem one can see with this is that SPARQL, though not that difficult to learn, is perhaps a bit too powerful for what is needed. You can really ask anything of a SPARQL endpoint!

A possible intermediary proposal: semantic forms

What is really going on here? Let us think in simple HTML terms, and forget about machine readable data a bit. If this were done for a human being, what we really would want is a page that looks like the webfinger.org site, which currently is just one query box and a search button (just like Google's front page). Let me reproduce this here:

Here is the html for this form as its purest, without styling:

     <form  action='/lookup' method='GET'>
         <img src='http://webfinger.org/images/finger.png' />
         <input name='email' type='text' value='' />         
         <button type='submit' value='Look Up'>Look Up</button>
     </form>

What we want is some way to make it clear to a robot, that the above form somehow maps into the following SPARQL query:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?homepage
WHERE {
   [] foaf:mbox ?email;
      foaf:homepage ?homepage
}

Perhaps this could be done with something as simple as an RDFa extension such as:

     <form  action='/lookup' method='GET'>
         <img src='http://webfinger.org/images/finger.png' />
         <input name='email' type='text' value='' />         
         <button type='submit' value='homepage' 
                sparql='PREFIX foaf: <http://xmlns.com/foaf/0.1/> 
                 GET ?homepage
                 WHERE {
                   [] foaf:mbox ?email;
                      foaf:homepage ?homepage
                 }">Look Up</button>
     </form>

When the user (or robot) presses the form, the page he ends up on is the result of the SPARQL query where the values of the form variables have been replaced by the identically named variables in the SPARQL query. So if I entered henry.story@sun.com in the form, I would end up on the page http://sun.com/lookup?email=henry.story@sun.com, which could perhaps just be a redirect to this blog page... This would then be the answer to the SPARQL query

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?homepage
WHERE {
   [] foaf:mbox "henry.story@bblfish.net";
      foaf:homepage ?homepage
}
(note: that would be wrong as far as the definition of foaf:mbox goes, which relates a person to an mbox, not a string... but let us pass on this detail for the moment)

Here we would be defining a new GET method in SPARQL, which find the type of web page that the post would end up landing on: namely a page that is the homepage of whoever's email address we have.

The nice thing about this is that as with Toby Inkster's proposal we would only need one new relation from the home page to such a finder page, and once such a sparql form mapping mechanism is defined, it could be used in many other ways too, so that it would make sense for people to learn it. For example it could be useful to make web sites available to shopping agents, as I had started thinking about in RESTful semantic web services before RDFa was out.

But most of all, something along these lines, would allow services to have a very simple CGI to answer such a query, without needing to invest in a full blown SPARQL query engine. At the same time it makes the mapping to the semantics of the form very clear. Perhaps someone has a solution to do this already. Perhaps there is a better way of doing it. But it is along these lines that I would be looking for a solution...

(See also an earlier post of mine SPARQLing AltaVista: the meaning of forms)

How this relates to OpenId and foaf+ssl

One of the key use cases for such a Web Finger comes from the difficulty people have of thinking of URLs as identifiers of people. Such a WebFinger proposal if successful, would allow people to type in their email address into an OpenId login box, and from there the Relying Party (the server that the user wants to log into), could find their homepage (usually the same as their OpenId page), and from there find their FOAF description (see "FOAF and OpenID").

Of course this user interface problem does not come up with foaf+ssl, because by using client side certificates, foaf+ssl does not require the user to remember his WebID. The browser does that for him - it's built in.

Nevertheless it is good that OpenId is creating the need for such a service. It is a good idea, and could be very useful even for foaf+ssl, but for different reasons: making it easy to help people find someone's foaf file from the email address could have many very neat applications, if only for enhancing email clients in interesting new ways.

Updates

It was remarked in the comments to this post that the format for the /host-meta format is now XRD. So that removes one criticism of the first proposal. I wonder how flexible XRD is now. Can it express everything RDF/XML can? Does it have a GRDDL?

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:

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:

  1. An ontology describing the public keys, the symmetric keys, the encrypted contents,...
  2. Mime types for encrypted contents
  3. 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....

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.

Thursday Oct 15, 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.

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.

  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. You agree to give Print.com access, but only for 1 hour.
  6. 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.
  7. 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.
  8. 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:

  1. Your browser GETs print.com's home page, which returns a page with a "publish my photos" button.
  2. 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.
  3. 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.
  4. 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.
  5. You give print.com access for 1 hour by filling in the forms.
  6. You give access rights to Print.com to your individual pictures using the excellent user interface available to you on your server.
  7. 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.
  8. 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

Creative Commons License
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.

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.

Tuesday Sep 29, 2009

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.

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.

Friday May 29, 2009

Link Roundup for Friday 29 May 2009

Linked Data is getting a lot of press:

On a the Social Web front:

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

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, affinity 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.

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.

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.

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.

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.

Firefox encryption tag

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.

my certificates.

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.

mail in iphone

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).

iphone install profile window

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.

enter certificate password

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.

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:

empty foaf.me page

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.

login 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:

certificate selection

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!

personalised foaf.me

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.

activity stream

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.

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.

  1. Go to an OpenId enabled service - I tried DZone and Identi.ca.
  2. Enter your OpenId - I used http://bblfish.net/ - in the provided field. And click return.
  3. 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.
  4. 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:

  1. 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.
  2. 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.
  3. 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.

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!

self signed certificate

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

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

A better analogy

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

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

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

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

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

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

The Web of Trust

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

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

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

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

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.

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.

  1. 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)
  2. When Romeo clicks the login button he opens an https request to the foaf+ssl+openid service.
  3. 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.
  4. The server looks in the client certificate for the Subject Alternative Name in the SSLv3 extensions, and fetches the foaf file at that URL
  5. 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 )
  6. 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. foaf+ssl+openid sequence diagram
  7. The browser then redirects to the Original service.
  8. 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.))
  9. Having verified the identity of the user, the service could optionally GET the user's foaf file, for public information about him.
  10. Or it could check the relation that user has to it's trusted graph of friends,
  11. 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.

About

bblfish

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today