FOAF & SSL: creating a global decentralised authentication protocol

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

Attending:

Henry Story

Contributors:

Bruno Harbulot, Ian Jacobi, Toby Inkster

Enthusiastic:

Melvin Carvalho

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:

1. A web page points to a protected resources using a https URL, e.g. https://juliette.net/location
2. The client fetches the secure http URL .
3. As part of that exchange the server requests the client certificate. The client returns Romeo's (possible self signed) 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 public key 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)
   

4. Juliet's server dereferences the URI found in the certificate, fetching a document .
5. The document's log:semantics is queried for information regarding the public key contained in the previously mentioned X.509. This can be done in part with a SPARQL query such as:

   PREFIX cert: <http://www.w3.org/ns/auth/cert#>
   PREFIX rsa: <http://www.w3.org/ns/auth/rsa#>
   SELECT ?modulus ?exp
   WHERE { 
      ?key cert:identity <http://romeo.net/#romeo>;
           a rsa:RSAPublicKey;
           rsa:modulus [ cert:hex ?modulus; ];
           rsa:public_exponent [ cert:decimal ?exp ] .   
   }                   
   

   If the public keys in the certificate is found to be identical to the one published in the foaf file, the server knows that the client has write access over the http://romeo.net/ resource.
6. Romeo's identity is then checked as to its position in a graph of relations (including frienship ones) 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.
7. Access is granted or denied .

We have tested this on multiple platforms in a number of different languages, (Java™, Python, ...) 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, the problems we have encountered and where we think this is leading us to next.