foaf+ssl: adding security to open distributed social networks

For the "W3C Workshop on the Future of Social Networking", taking place in Barcelona January 2009

Contributors:

Semantic Web vocabularies such as foaf permit distributed hyperlinked social networks to exist. We would like to discuss a group of related ways we are exploring (mailing list) to add information and services protection to such distributed networks.

One major criticism of open networks is that they seem to have no way of protecting the personal information distributed on the web or limiting access to resources. Few people are willing to make all their personal information public, many would like large pieces to be protected, making it available only to a select group of agents. Giving access to information is very similar to giving access to services. There are many occasions when people would like services to only be accessible to members of a group, such as allowing only friends, family members, colleagues to post a blog, photo or comment on a site. How does one do this in a maximally flexible way, without requiring any central point of access control?

Using an intuition made popular by OpenID we show how one can tie a User Agent to a URI by proving that he as write access to it. foaf+ssl is architecturally a simpler alternative to OpenID (fewer connections), that uses X.509 certificates to tie a User Agent (Browser) to a Person identified via a URI. However, foaf+ssl can provide additional features, in particular, some trust management, relying on signing FOAF files, in conjunction with set of locally trusted keys, as well as a bridge with traditional PKIs. By using the existing SSL certificate exchange mechanism, foaf+ssl integrates more smoothly with existing browsers including mobile devices, and permits automated sessions in addition to interactive ones.

The steps in the protocol can be summarised simply:

A web page points to a protected resources using a https URL, e.g. https://juliette.net/location The client fetches the secure http URL . As part of that exchange the server requests the client certificate. The client returns Romeo's certificate, containing the little known X.509 v3 extensions section: X509v3 extensions: ... X509v3 Subject Alternative Name: URI:http://romeo.net/#romeo Because the connection is encrypted, Juliet's server knows that Romeo's client knows the private key of the certificate that is also passed in the certificate Something like: 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) Juliet's server dereferences the URI found in the certificate, fetching a document . The document's log:semantics is queried for information regarding the public key published in the X.509. If this is successful, the server knows that the client has write access over that resource. The position of the resource referred to by the URI is checked as to its position in a graph of friends in order to determine trust according to some criteria . Juliet's server can get this information by crawling the web starting from her foaf file, or by other means. Access is granted or denied .

We have tested this on multiple platforms in a number of different languages, (java, ...) and across a number of existing web browsers (Firefox, Safari, more to come).

foaf+ssl is one protocol that we would like to concentrate on due to its simplicity. But there are a number of other ways of achieving the same thing, by using OpenID for example. All of them require some extra pieces:

An ontology to describe what can be done with the data (copied, republished,...) or what obligations incur in using a service .

An ontology to describe who has access to the service. This would be useful to help people decide if they should bother trying to access it, or what else they need to do such as become friends with someone, or reveal a bug in the software somewhere .

Other things that might come up .

We will discuss our experience implementing this.