[foaf-dev] for more information please log in

Story Henry henry.story at bblfish.net
Fri Jan 18 18:43:21 GMT 2008 

On 18 Jan 2008, at 19:22, Peter Williams wrote:
> 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".

The open id and the foaf Id will always be different, as an openid is  
what is known in foaf as a foaf:Document and the class of foaf:Agent-s  
and foaf:Document-s have no members in common.

They can be related via the inverse functional foaf:openid relation

:me foaf:openid <http://openid.sun.com/bblfish> .

The PGP proposal was just an attempt to show that one can easily use  
any number of authentication protocols. I just invented one that  
seemed like it could be more practical than OpenId.


> 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?

I just want to be able to describe in RDF that certain resources are  
accessible to a certain group, and be able to specify what type of  
authentication mechanisms are accepted, so that agents can decide if  
they think they are members of the group and if it is worth  
authenticating to get the extra information. IE. I am just trying to  
find the RDF equivalent of the text you see on sites like FaceBook:  
"Please log in here to access the content".


Now as I mentioned I think OpenId is nice as a unique ID for human  
readable web sites, but it is also a little heavy handed as it  
requires quite a lot of back and fro between the browser the server  
and the service. I was just thinking out loud if one could not get a  
much simpler authentication scheme using PGP and foaf...

I did not say this was required.

> -----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.
>
>
> 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/15ad9b46/smime.bin

More information about the foaf-dev mailing list