[foaf-dev] for more information please log in
michael.wechner at wyona.com
Sun Jan 13 21:42:51 GMT 2008
Story Henry wrote:
>> Story Henry wrote:
>>> If a foaf file is to return different representations depending on
>>> the authentication level of the person looking at it, there needs
>>> to be some way for the foaf file to say that. Something like: for
>>> a larger view you may want to log in there: http://...
>>> Any thoughts on this?
>> I don't think this has anything to do with the FOAF itself, but
>> rather with the functionality of the hosting provider serving the FOAF.
> Well it does not have to do with foaf in that this is a problem that
> can be generalised to any vocabulary. As mentioned in my reply to
> Dan, I just asked the question on this list because we have a use
> case that is getting traction.
agreed (and also an itch for myself to scratch ...)
> On the other hand the link to the login point will have to be in the
> foaf representation, otherwise the client reading the foaf file will
> have no way of finding that login point.
I don't think one has necessarily to put this into the FOAF
represetation, but rather it could be done through a service, just as
for instance sending invitations (see some more usecases at
I think the client somehow needs to know the service URL, which could be
part of the FOAF representation, but then the client could retrieve all
the other usecases (e.g. authentication, invitation, etc.) through this
>> I would expect the hosting provider to provide an OpenID login,
>> where you can specify your OpenID and the person who owns the
>> profile can set rights for your OpenID associated with the content
>> of the FOAF (assuming that the hosting provider offers such
> yes. right. For example once I have logged in with an open id the
> foaf provider could return me the full foaf:PersonalProfileDocument
> including foaf:knows relations, because my openid is listed as one of
> the people the foaf:primaryTopic of the foaf file foaf:knows.
> It could also go and fetch a foaf file associated with my foaf
> openid, and from there find some information that may allow it to
> decide that I am part of a network, and so perhaps allow me to see
> more information that the minimal amount.
>> One implementation could look like
>> <foaf:phone rdf:resource="tel:+41-44-272-91-61">
>> <s:policy xmlns:s="http://www.wyona.org/security/1.0">
>> <s:usecase id="view">
>> <s:user openid="http://bblfish.videntity.org/" permission="true"/>
>> <s:user id="socrates" permission="true"/>
>> <s:user id="aristotle" permission="true"/>
>> whereas as said this hosting provider specific implementation.
> I am not sure what you are trying to do here. I don't think we want
> to specify policy on a relation basis.
as said this is just a very specific implementation how an access policy
could be associated with a FOAF element and just should illustrate how
fine-grained one could do access control.
But this would all be hidden within the server implementation and the
client has now clue about this, but only has to find out the service for
>> Btw, how should one handle multiple openid, e.g. your FOAF contains
>> <openid rdf:resource="http://bblfish.videntity.org/"/>
>> <openid rdf:resource="http://openid.sun.com/bblfish"/>
> Well by logging in with openid the foaf server could find my foaf file,
is there some standard for this?
> and thereby discover my other openids. Would it want me to verify
> those ids too?
if I have added only one OpenID to my access policy, but you will login
with your other openid, then I won't allow you to see the information
which you are actually supposed to see, unless I am somehow able to
deduce your second openID from your first (e.g. via your FOAF if possible)
>> One could also imagine that the FOAF URL is used as login input and
>> the server application is then looking up the OpenID from the FOAF ...
> Yes. There are quite a few different ways to do this.
> I think that if we could settle on one, and have some python or ruby
> script that can easily be deployed to an Apache server implement
> this, that could make a lot of impact on the "data portability"
I will definitely implement something like this into Yanel/FOAF
(http://foaf.wyona.org/developers.html), but it would be great to have
some other server implementation out there to test compatibility.
>>> Home page: http://bblfish.net/
>>> foaf-dev mailing list
>>> foaf-dev at lists.foaf-project.org
>> Michael Wechner
>> Wyona - Open Source Content Management - Yanel, Yulup
>> michael.wechner at wyona.com, michi at apache.org
>> +41 44 272 91 61
Wyona - Open Source Content Management - Yanel, Yulup
michael.wechner at wyona.com, michi at apache.org
+41 44 272 91 61
More information about the foaf-dev