The Sun BabelFish Blog

FOAF & SSL: creating a global decentralised authentication protocol

Following on my previous post RDFAuth: sketch of a buzzword compliant authentication protocol, Toby Inkster came up with a brilliantly simple scheme that builds very neatly on top of the Secure Sockets Layer of https. I describe the protocol shortly here, and will describe an implementation of it in my next post.

Simple global ( passwordless if using a device such as the Aladdin USB e-Token ) authentication around the web would be extremely valuable. I am currently crumbling under the number of sites asking me for authentication information, and for each site I need to remember a new id and password combination. I am not the only one with this problem as the data portability video demonstrates. OpenId solves the problem but the protocol consumes a lot of ssl connections. For hyperdata user agents this could be painfully slow. This is because they may need access to just a couple of resources per server as they jump from service to service.

As before we have a very simple scenario to consider. Romeo wants to find out where Juliette is. Juliette's hyperdata Address Book updates her location on a regular basis by PUTing information to a protected resource which she only wants her friends and their friends to have access to. Her server knows from her foaf:PersonalProfileDocument who her friends are. She identifies them via dereferenceable URLs, as I do, which themselves usually (the web is flexible) return more foaf:PersonalProfileDocuments describing them, and pointing to further such documents. In this way the list of people able to find out her location can be specified in a flexible and distributed manner. So let us imagine that Romeo is a friend of a friend of Juliette's and he wishes to talk to her. The following sequence diagram continues the story...

The stages of the diagram are listed below:

1. First Romeo's User Agent HTTP GETs Juliette's public foaf file located at http://juliette.net/. The server returns a representation ( in RDFa perhaps ) with the same semantics as the following N3:

   @prefix : <#> . 
   @prefix foaf: <http://xmlns.com/foaf/0.1/> .
   @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
   @prefix todo: <http://eg.org/todo#> .
   @prefix openid: <http://eg.org/openid/todo#> .
   
   <> a foaf:PersonalProfileDocument;
      foaf:primaryTopic :juliette ;
      openid:server <https://aol.com/openid/service>; # see The Openid Sequence Diagram .
   
   :juliette a foaf:Person;
      foaf:name "Juliette";
      foaf:openid <>;
      foaf:blog </blog>;    
      rdfs:seeAlso <https://juliette.net/protected/location>; 
      foaf:knows <http://bblfish.net/people/henry/card#me>,
                 <http://www.w3.org/People/Berners-Lee/card#i> .
   
   <https://juliette.net/protected/location> a todo:LocationDocument .
   

   Romeo's user agent receives this representation and decides to follow the https protected resource because it is a todo:LocationDocument.

2. The todo:LocationDocument is at an https URL, so Romeo's User Agent connects to it via a secure socket. Juliette's server, who wishes to know the identity of the requestor, sends out a Certificate Request, to which Romeo's user agent responds with an X.509 certificate. This is all part of the SSL protocol.

   In the communication in stage 2, Romeo's user agent also passes along his foaf id. This can be done either by:

   • Sending in the HTTP header of the request an Agent-Id header pointing to the foaf Id of the user. Like this:

     Agent-Id: http://romeo.net/#romeo
     

     This would be similar to the current From: header, but instead of requiring an email address, a direct name of the agent would be required. (An email address is only an indirect identifier of an agent).
   • The Certificate could itself contain the Foaf ID of the Agent in the X509v3 extensions section:

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

     I am not sure if it would be correct use of the X509 Alternative names field. So this would require more standardization work with the X509 community. But it shows a way where the two communities could meet. The advantage of having the id as part of the certificate is that this could add extra weight to the id, depending on the trust one gives the Certificate Authority that signed the Certificate.

3. At this point Juliette's web server knows of the requestor (Romeo in this case):
   • his alleged foaf Id
   • his Certificate ( verified during the ssl session )

   If the Certificate is signed by a CA that Juliette trusts and the foaf id is part of the certificate, then she will trust that the owner of the User Agent is the entity named by that id. She can then jump straight to step 6 if she knows enough about Romeo that she trusts him.

   Having Certificates signed by CA's is expensive though. The protocol described here will work just as well with self signed certificates, which are easy to generate.

4. Juliette's hyperdata server then GETs the foaf document associated with the foaf id, namely <http://romeo.net/> . Romeo's foaf server returns a document containing a graph of relations similar to the graph described by the following N3:

   @prefix : <#> . 
   @prefix foaf: <http://xmlns.com/foaf/0.1/> .
   @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
   @prefix wot: <http://xmlns.com/wot/0.1/> .
   @prefix wotodo: <http://eg.org/todo#> .
   
   <> a foaf:PersonalProfileDocument;
       foaf:primaryTopic :romeo .
   
   :romeo a foaf:Person;
       foaf:name "Romeo";
       is wot:identity of [ a wotodo:X509Certificate;
                            wotodo:dsaWithSha1Sig """30:2c:02:14:78:69:1e:4f:7d:37:36:a5:8f:37:30:58:18:5a:
                                                f6:10:e9:13:a4:ec:02:14:03:93:42:3b:c0:d4:33:63:ae:2f:
                                                eb:8c:11:08:1c:aa:93:7d:71:01""" ;
                          ] ;
       foaf:knows <http://bblfish.net/people/henry/card#me> .
   

5. By querying the semantics of the returned document with a SPARQL query such as

   PREFIX wot: <http://xmlns.com/wot/0.1/> 
   PREFIX wotodo: <http://eg.org/todo#> 
   
   SELECT { ?sig }
   WHERE {
       [] a wotodo:X509Certificate;
         wotodo:signature ?sig;
         wot:identity <http://romeo.net/#romeo> .
   }
   

   Juliette's web server can discover the certificate signature and compare it with the one sent by Romeo's user agent. If the two are identical, then Juliette's server knows that the User Agent who has access to the private key of the certificate sent to it, and who claims to be the person identified by the URI http://romeo.net/#romeo, is in agreement as to the identity of the certificate with the person who has write access to the foaf file http://romeo.net/. So by proving that it has access to the private key of the certificate sent to the server, the User Agent has also proven that it is the person described by the foaf file.

6. Finally, now that Juliette's server knows an identity of the User Agent making the request on the protected resource, it can decide whether or not to return the representation. In this case we can imagine that my foaf file says that

    @prefix foaf: <http://xmlns.com/foaf/0.1/> .
   
    <http://bblfish.net/people/henry/card#me> foaf:knows <http://romeo.net/#romeo> .  
    

   As a result of the policy of allowing all friends of Juliette's friends to be able to read the location document, the server sends out a document containing relations such as the following:

   @prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#> .
   @prefix : <http://juliette.org/#> .
   
   :juliette 
       contact:location [ 
             contact:address [ contact:city "Paris";
                               contact:country "France";
                               contact:street "1 Champs Elysees" ]
                        ] .
   

Todo

• Create an ontology for X509 certificates.
• test this. Currently there is some implementation work going on in the so(m)mer repository in the misc/FoafServer directory.
• Can one use the Subject Alternative name of an X509 certificate as described here?
• For self signed certificates, what should the X509 Distinguished Name (DN) be? The DN is really being replaced here by the foaf id, since that is where the key information about the user is going to be located. Can one ignore the DN in a X509 cert, as one can in RDF with blank nodes? One could I imagine create a dummy DN where one of the elements is the foaf id. These would at least, as opposed to DN, be guaranteed to be unique.
• what standardization work would be needed to make this

Discussion on the Web

• Peter Williams is very positive, in his response on the OpenId mailing list where he gives a short overview of the history of the URI Subject Alternative name in the X509 spec.
• Paul Madsen gives a short description of how this would be implemented in the Liberty stack.
• The foaf+ssl proposal here is placed in the larger context in the audio presentation "Building Secure, Open and Distributed Social Network Applications".

Posted at 02:00PM Apr 21, 2008 [permalink/trackback] by Henry Story in SemWeb  |  Comments[4]