[foaf-dev] for more information please log in

[Story Henry]

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.


Henry


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 .

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2429 bytes
Desc: not available
Url : http://lists.usefulinc.com/pipermail/foaf-dev/attachments/20080118/81e77bd5/smime.bin