[foaf-dev] for more information please log in

Peter Williams pwilliams at rapattoni.com
Fri Jan 18 18:22:52 GMT 2008

The proposal to use a foaf id (within a rsa/dss/ecc-dsa authentication protocol (using the pgp products message formats)) worries me : the openid (used in the openid auth protocol) may or may not be the same as the "foaf id".

Do we really want "foaf ids" to become a system of identication of the ppd owner, or should a ppd always delegate identification to another scheme (eg openid) under the inverse functional rules?

-----Original Message-----
From: Story Henry <henry.story at bblfish.net>
Sent: Friday, January 18, 2008 2:55 AM
To: Danny Ayers <danny.ayers at gmail.com>
Cc: foaf-dev <foaf-dev at lists.foaf-project.org>
Subject: Re: [foaf-dev] for more information please log in

In summary I think the following pattern proposed by Dave Brondsema  
looks right.

<public> rdfs:seeAlso <protected> .

<protected> readableBy SomeGroup;
             login [ = </login>;
                     a OpenidLoginService ].

Of course the readableBy would be optional, as most things in the  
semantic web, due to the open world assumption.

One thing to solve would be how to define the group without specifying  
the members (that would be giving too much information away :-) One  
could have a few predetermined groups such as Friend, FriendOfAFriend,  
Family, and Colleagues, to start off with, and generalise from that.

I suppose there my be other ways of allowing the User Agent to specify  
his identity.
One could imagine a simple protocol, called PGP_ID perhaps, where all  
the client needs
to do is send the following headers in HTTP request

FOAF-ID: http://bblfish.net/people/henry/card#me
Encrypted-String: kjsdkfjlskdjflskjdflskjdflksjdf

which could identify the user, me, because the foaf id points to a  
foaf file, which points to a PGP public key, and the encrypted string  
would be an encrypted string proposed by the foaf file and encrypted  
with the user's private key. The server would just need to download  
the foaf file, find the public key, and verify that the encrypted  
string was encrypted using that public key.

So there we might have

<public> rdfs:seeAlso <protected> .

<protected> readableBy [ a FriendOfAFriendGroup;
                          relatedto :me ];
             pgp_id_key "2008-02-10" .

That would reduce traffic on the client side a lot, as the client  
would not have to go through all the redirect rigamarole of openid. It  
should not be surprising that one can cut down dramatically on the  
complexity of OpenId. They designed their protocol with limitations of  
the web browsers in mind. But since current web browsers don't  
understant rdf anyway, we should not limit ourselves this way. Beatnik  
and future hyperdata browsers/editors are just being built.

But I have not thought through the security implications of this.


On 13 Jan 2008, at 22:47, Danny Ayers wrote:
> <public> a PersonalProfileDocument;
> primaryTopic <#me> ;
> http-auth:authorization http-auth:authorization#None .
> <private> a PersonalProfileDocument;
> primaryTopic <#me> ;
> http-auth:authorization http-auth:authorization#Digest .
> Or is that too close to the auth implementation? Might it be better  
> like:
> <private> a PersonalProfileDocument;
> primaryTopic <#me> ;
> auth:authorized  <(members of groupX)> .
> - closer to the W3C ACL stuff??
> http://www.w3.org/2001/04/20-ACLs.html

There you are having the documents define their own access control.  
That is not so useful for an agent that has not read the document yet:  
catch 22.

The W3C ACL stuff is a good place to look for guidance. Thanks.

On 14 Jan 2008, at 05:31, Dave Brondsema wrote:
> Two small suggestions: I would make the "forGroup FriendsOfMyFriends"
> part optional.  In some cases it may not be practical to name the  
> group,
> and I don't see the advantage of naming the group (except human
> readers).  For example, if the authentication-required foaf is  
> generated
> dynamically there may be complex sets of rules for all sorts of people
> and no need or way to name groups.
> Secondly, is there a way to use rdfs:seeAlso, so that clients that
> already understand that predicate can possibly use this as well?   
> Perhaps:
> <> rdfs:seeAlso <http://bblfish.net/people/card/henryFriends>
> <http://bblfish.net/people/card/henryFriends> login </login>
> <> rdfs:seeAlso <http://bblfish.net/people/card/henryFamily>
> <http://bblfish.net/people/card/henryFamily> login </login>
> </login> a OpenidLoginService .

More information about the foaf-dev mailing list