| 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 target.com using the account information at source.com and using FOAF as the transport mechanism. In addition, target.com should populate the friends list with people Alice knows at source.com who are already members. Export: 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 target.com to pass Alice's approval to source.com. So for testing, Alice will have to use a browser to save the source.com FOAF file locally. That way we can use existing login processes to authenticate. But then Alice will have to manually upload the FOAF to target.com 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. Import: 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. Federation: 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. Authentication: Anywhere ID+Password is used there's a potential security risk. So ideally the source.com credentials should never be given to target.com 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 source.com 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 ]
