Here's a post from the FOAFnet mailing list. I'm going to copy a collection of the critical ones here.

FOAFnet Aims:
We want to get to the point where Alice can create a new account at using the account information at and using FOAF as the transport mechanism. In addition, should populate the friends list with people Alice knows at who are already members.

No site is going to export contact information for Alice without Alice's approval. Publicly accessible FOAF for Alice should not include contact info because Alice doesn't get the chance to approve the export.

Equally, even if Alice gives approval, Alice's friend Bob hasn't, so we should never put Bob's contact info into Alice's FOAF. But we can put in mbox_sha1sum or other IFPs like homepage URL so that existing members can be matched.

We don't have a mechanism for an application at to pass Alice's approval to So for testing, Alice will have to use a browser to save the FOAF file locally. That way we can use existing login processes to authenticate. But then Alice will have to manually upload the FOAF to either by a file browse control or by pasting it into a textarea. This is not a long term solution. But it will let us do a proof of concept and write all the import routines.

We still have to write the first import routine. Even using the stone age manual methods described. We've now got some Java and PHP routines that can help.

In a final system, we can imagine groups of large sites that agree to import from each other. The numbers are likely to be relatively small so a drop down list could be provided to the user. The user will still have to provide some ID (like an ID#, nick or email address) and some authentication like a password.

We'll need some backend admin to define for each participating site how to collect the FOAF and how to pass the ID and password.

We can also imagine large numbers of smaller sites that would like to participate and any one target cannot maintain a list of all of them. So if the target will accept any of them, we'll have to provide a URL text field, the API to use, as well as the ID+Password. It may be possible to combine these into fewer fields the way Drupal has done with their external login. Even if the sites are distributed they may use some standard or be based on the same software. So we might be able to solve this generically for any Drupal, Typepad, Movable type, Wordpress, Jabber, LDAP site and so on.

Anywhere ID+Password is used there's a potential security risk. So ideally the credentials should never be given to but should use a single signon and temporary key method. The use cases for this and programming patterns have been well documented by the Liberty group.

This whole authentication area is not really part of FOAFnet but it's unavoidable because we're talking about information that users rightly consider private.

Unfortunately there's no big market leader here with a protocol that has usable implementations on all likely platforms. We have to count out Passport and Liberty mainly due to platform issues. So this is an opportunity for a new player to appear whether commercial/proprietary or free/open source.

FOAFnet Road Map:
So. Hit the Road, Map.
1) Build FOAF Export using existing authentication
1a) Get existing FOAF export up to scratch
2) Build FOAF Import from saved files
3) Solve remote authentication
4) Build UI to let the user choose a for their FOAF and get the FOAF at run time

[ << August 2009: How Google beat Amazon and Ebay to the Semantic Web ] [ FOAFnet Authentication - A proposal >> ]
[ 31-Jul-04 8:43am ]