The Sun BabelFish Blog

Don't panic !

« Previous page | Main | Next page »

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]

Wednesday Jan 21, 2009

Outline of a business model for open distributed social networks

The organisers of the W3C Workshop on the future of social networking had the inspiration to include a track on Business Models. What would be the interest of large players to open up? to play ball in a larger ecosystem of social networks? What would the business model be for new entrants? This question clearly was on many of the attendees minds, and it is one I keep coming across.

First without Linked Social Networks there are a lot of disincentives to create new web services. This is because users of these services need to duplicate the data they have already created elsewhere, and also because the network effect of the data they are using is bound to be much smaller. I have found myself uninterested in trying out many new web 2.0 offerings for just these reasons. It is much more rewarding for developers to create applications for the Facebook platform for example, where the users just need to click a button to try out the application on the data they are already using, and that may yet enrich this data further.

Open Secure Linked Social Networks, such as that made possible by foaf+ssl, give one the benefits enjoyed by application developers of the closed social networks but in a distributed space, which should allow the unleashing of a huge amount of energy. Good for the consumer. But good for the big network players? I will argue that they need consider the opportunities this is opening up.

First of all one should notice that the network effect applies just as much to the big players as to the small ones. A growing distributed social network (SN) is a tide that will lift all boats, and since metcalf's law states that the value of the network grows exponentially with the number of nodes in it, then doubling the number of nodes in the network may just quadruple the value of the network to all. Perhaps the big operators are thinking that they control such a large slice of the market that there is not much doubling that they can do by linking to the smaller players. As it happens most social networks are geographical monopolies, which would go to strengthen that point of view (see slide 8 of the opening presentation at the W3C workshop). [ Nothing stays still, and everyone should watch out for the potential SN controlled by the telecoms.]

But the network effect applies to the big players also in another way. Namely that if they wish to create small networks then the value of those networks will be just as insignificant as those of other smaller players. So let me take a simple example of very valuable smaller networks which have a huge and unsatisfied demand for social networking technologies and the money to pay for tools that could help them quench their need: companies! Companies need to connect their employees to their managers and colleagues inside the same company, to knowledge resources, to paychecks and many other internal resources such as wikis, blogs, etc... Usually companies of a large enough size have software to deal with these. But even in a company such as Sun Microsystems, that is relatively large, the network effect of that information is not interesting enough for people to participate gladly in keeping the information up to date. I often find it easier to go to Facebook to find a picture of someone in Sun. Why? Well there is a very large value in adding one's picture to facebook: 200 million other users to connect to. In Sun Microsystems only 34 thousand people to connect to, and it is true a financial incentive. Clearly the value of 200 million squared is larger than the incentive of being efficient at work.

One thing is clear: it is impossible to imagine that such large software companies can allow their employees to just use the closed SN sites directly to do their work - I mean here: have all their employess just use the tools on facebook.com for example. This would give those SN companies way too much insight into the dealings of the company. Certainly very large sections of industry, including defence contractors, large competitive industries such as car manufacturers, and governments, cannot legally and strategically permit such outsourcing to happen, even though the value of the information in such a large network would be astronomically larger. In some case there are serious privacy and security issues that just cannot be ignored however attractive the value calculation is.

So large SN players would have to enter the Fortune 1000 with Social Networking software that did not leak information. But in that case they won't be in any seriously better position than the software that is already in there, and they won't be able to compete any better than any of the smaller companies that are working in this space, as they will not find it easy to leverage their main advantage, namely the network effect of their core offering.

And even if they did manage to leverage this in some ways, they would find it impossible to leverage that advantage in the ways that really count. Companies don't just want their employees to link up with their colleagues, they need them to link up with people outside their company, be it customers, government agencies, researchers, competitors, external contractors, local governement, insurance or health agencies, etc, etc..... The list is huge. So even if a large Social Network could convince one of these players of the advantage of their offering, they will never be able to convince every single partner of that company - for that would be to convince the whole world. Companies really want global SN, and that is what Emergency Response teams really need.

To make such a globaly linkable platfrom a reality one needs to build at the level of abstraction and clarity at which the only such global network in existence is built: the web itself. By using Linked Data one can create distributed social networks where each player can maintain the information they feel the business need to maintain. With the very simple foaf+ssl protocol we have the lightest possible means to build security into a distributed social network. Simplicity and clarity - mathematical clarity - is essential when developing something that is to grow to a global scale.

Companies therefore that work at providing tools for distributed social networks, will if they play well together, find a huge opportunity opening up in front of them in helping enterprises in every industry segment link up their employees to people in every walk of life.

Posted at 12:53PM Jan 21, 2009 [permalink/trackback] by Henry Story in General | Comments[1]

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]

Tuesday Dec 30, 2008

foaf+ssl, pki and the duck-rabbit

In part II §xi of the "Philosophical Investigations", Ludwig Wittgenstein introduces the duck-rabbit figure:

I shall call the following figure derived from Jastrow, the duck-rabbit. It can be seen as a rabbit's head or as a duck's. And I must distinguish between the 'continuous seeing' of an aspect and the 'dawning' of an aspect.

The picture might have been shewn me, and I never have seen anything but a rabbit in it.

It is worth stopping here and considering that illustration carefully, making sure you can see it one way then the other. There is no illusion here notice. There is not one correct way to see the line. The figure itself is ambiguous. The duck-rabbit therefore shows very simply how the way we perceive the world can change without any new fact appearing in the world.

Is that not what magic does?

Much more complex examples of this phenomenon can be found. In some cases it is much more difficult to switch between meanings. I find this for the Young Woman Old Woman image for example. I really need to work hard there to see the other interpretation, and when I find that interpretation I find switching back very difficult.

Recently I have felt that the foaf+ssl protocol does something similar to Public Key Cryptography (PKI). We use a tool that was always meant to be used one way, in a completely different way, a way of course that was always permitted, but that nobody saw (or if they did they did not pursue it openly).

To perceive this different way of using this tool one has to - just as with the duck-rabbit - look at it differently. One has to see it in a new way, or perhaps even use it in a new way. Whereas PKI is used for hierarchical trust, we use it to build a web of trust. Where X509 certs built up a lot on the Distinguished Name hierarchy, we nearly ignore it. Where X509 tried to place information in the certificate, we place it outside at the name location. Even though SSL can request client certificates in the browser, nobody does this, yet we build on this little known feature. Self signed client certificates, which would not have made sense in traditional PKI infrastructure, because they proove nearly nothing about the client, is what we build everything on....

All the usual X509 and ssl tools work just as they should, but magically it seems they are suddenly found to be doing something completely different.

Posted at 09:08PM Dec 30, 2008 [permalink/trackback] by Henry Story in SemWeb | Comments[4]

Friday Dec 19, 2008

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

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

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

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