[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.
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 .
More information about the foaf-dev
mailing list