[foaf-protocols] creating a cert service

Henry Story Henry.Story at Sun.COM
Thu Jan 22 21:04:31 CET 2009

In order to keep things as simple as possible I thought it would be  
useful to create a cert service that would do just one thing: create  
using spkac (and the M$ equivalent) a cert for a user, and create an  
rdf file available online to go with it.

The idea is that there are a number of existing services such as  http://foafbuilder.qdos.com/ 
  , the work Melvin is doing at foaf.me, or the knowee software - to  
cite a few off the top of my head - which are designed to help people  
keep their foaf profiles up to date, link those with other foaf  
servers, and do all kinds of advanced and fun stuff that I will not  
have the time or the energy to develop at the moment. Furthermore  
there is no need to do this, since others are doing it very well. But  
what most of these other services are missing at present is a service  
to help people easily create a X509 certificate for their browser. I  
am sure they won't find any trouble adding that feature when they have  
seen a few demos of the power of this, but we first need the demos, so  
I thought it would be best to work on this missing piece, a task that  
I hope to be able to do a reasonable job of in under a week. Others  
can then later integrate it into their software stack, as it is all  
realeased under a BSD licence at https://sommer.dev.java.net/

So to do this I am going to

  1. create a simple form that asks the user for his foaf ID (pointing  
him to one of these other services to get one),
  2. then fetch that foaf, extract some information to present a  
personalised UI
  3. allow the user to create a cert and place some RDF for it on http://bblfish.net/ 
  somewhere, which the user can either use to fill in his foaf file,  
or which he can point to from other services.

So the RDF created would be something like:

@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix rsa: <http://www.w3.org/ns/auth/rsa#> .

<http://bblfish.net/cert/2009/01/21/c22#UA> a foaf:UserAgent;
     foaf:name "Firefox 3.01";
     is cert:identity of
           [ a rsa:RSAPublicKey;
             rsa:public_exponent "65537"^cert:decimal;
             rsa:modulus "862d6e0b8c3...."^cert:hex;
     foaf:ownedBy <http://foafbuilder.qdos.com/id/123123#me> .

If all the user wanted from his cert was for the services he is going  
to use to be able to recognize him over time, ie, if all he wants is  
identification, then there would be no need even for the foaf:ownedBy  
relation above.

But if the user also wants to tie that cert to the foaf file, then  
that ownedBy relation will become important, so that tools that find  
the UserAgent can find more information about the person behind it,  


It is </id/123123#me>  that people want to foaf:know, not the less  
stable <cert/2009/01/21/c22#UA> . Of course since anyone could create  
a user agent file as above, and claim it was ownedBy anyone, the foaf  
document </id/123123> should point back to the certificate as a  

Now one could argue that one need not create a foaf:UserAgent class,  
and instead just specify that URI to be a foaf:Person, and then link  
both using owl:sameAs . I wonder though if when doing that it may not  
be less clear to future software which of these URIs they should  
choose in preference to the other. In some ways in generating a  
private key with keygen we really are identifying the browser, since  
it is unlikely that many people will extract it and put it in another  
browser. On the other hand if Apple's KeyChain started being used by  
the other browsers, then the public key would not longer identify a  
particular user agent, but the computer...

So really the question is here: foaf:UserAgent, foaf:Agent or  
foaf:Person ? and how should I link the Agent to the main foaf file?


Blog: http://blogs.sun.com/bblfish

More information about the foaf-protocols mailing list