[foaf-dev] for more information please log in

[Michael Wechner]

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 
http://yanel.wyona.org/specification/foaf/index.html).

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 
service URL

>
>> 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  
>> functionality).
>
>
> 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"/>
>>   </s:usecase>
>> </s:policy>
>> </foaf:phone>
>>
>> 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 
authentication.

>
>
>> Btw, how should one handle multiple openid, e.g. your FOAF contains
>>
>> <nick>bblfish</nick>
>>       <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" 
> discussion.


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.

Cheers

Michael

>
> Henry
>
>
>>
>> Cheers
>>
>> Michael
>>
>>>
>>> Henry
>>>
>>>
>>> Home page: http://bblfish.net/
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> foaf-dev mailing list
>>> foaf-dev at lists.foaf-project.org
>>> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>>>
>>
>>
>> -- 
>> Michael Wechner
>> Wyona      -   Open Source Content Management - Yanel, Yulup
>> http://www.wyona.com
>> michael.wechner at wyona.com, michi at apache.org
>> +41 44 272 91 61
>
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management - Yanel, Yulup
http://www.wyona.com
michael.wechner at wyona.com, michi at apache.org
+41 44 272 91 61