[foaf-dev] for more information please log in

[Story Henry]

To make things really clear it is worth starting with a simple example.

I would like people who come to request my foaf file at
http://bblfish.net/people/henry/card

to get a minimal representation back. Perhaps something like this:

--------------------minimal public foaf----------------------------
<>   a foaf:PersonalProfileDocument;
      foaf:maker :me;
      foaf:title "Henry Story's FOAF file";
      foaf:primaryTopic :me.
:me    a foaf:Person;
        foaf:depiction <http://farm1.static.flickr.com/164/373663745_1801c2dddf.jpg?v=0 
 >;
        foaf:openid <http://openid.sun.com/bblfish> ;
        foaf:openid <http://bblfish.videntity.org/> ;
        foaf:gender "male";
        foaf:birthday "07-29";
        foaf:title "Mr";
        foaf:name "Henry J. Story";
        foaf:homepage <http://bblfish.net/> .

<> openid:loginForMoreInfo </login> .

--------------------end minimal public foaf----------------------------

A client that retrieves this representation and that recognises the  
openid:loginForMoreInfo
relation (or whatever is decided is the best solution to this  
problem), may decide that it is worth it identifying itself (how would  
it decide that? Perhaps this is where if I added the bloom filter  
described in http://blogs.sun.com/bblfish/entry/my_bloomin_friends to  
the above representation the client could decide that authentication  
is worth the trouble...)

Anyway so let us say the client ( Beatnik perhaps ) that is owned by  
Dan Brickley authenticates at <http://bblfish.net/login> with his  
openid. Having done that he can now request anew the resource <http://bblfish.net/people/henry/card 
 >. This time I suppose the request comes with a cookie in the header,  
or some token that allows the bblfish.net server to  recognise this  
request as coming from Dan Brickley. As it happens Dan Brickley is  
someone I know, and the server that builds the foaf file knows this,  
and so after consulting its policy for who can see what, decides that  
Dan can see the whole thing. I won't copy and paste the whole thing,  
as it is currently visible to all at that URL. It will be the above  
foaf file plus a list of all my friends, etc...

So how to do content negotiation, and how to build up representations  
on the fly is all well known.

What has not yet been standardised I think is how to alert the user  
agent that more information is available if he identifies himself.  
Also of interest may be to let the user agent know what extra  
information he may get if he is a member of a certain type of group,  
so that he can decide if he wants to log in. As other have mentioned,  
perhaps content negotiation is not the right way to proceed. Perhaps  
it should be a relation such as

<> more:infoAt [ forGroup FriendsOfMyFriends;
                  see <http://bblfish.net/people/card/henryFriends>;
                  login </login>],
	       [ forGroup Family;
                  see <http://bblfish.net/people/card/henryFamily>;
                  login </login>] .

Where perhaps the class of FriendsOfMyFriends and Family is defined in  
some way with OWL.


Henry


Home page: http://bblfish.net/

On 13 Jan 2008, at 23:21, Peter Williams wrote:

> In the discussion below, it finally became clear that the question  
> asked not about how to return a different presentation syntax (N3,  
> xml/rdf) depending on subject-authentication and FOAF-attributes in  
> the object under inspection, but how to apply infra-FOAF access  
> controls - controls that are a function of the security policy,  
> linking security-subjects and the authentication strength of their  
> network sessions to control attributes that are also indicated in  
> one or more FOAF security-objects.
>
> In some design traditions, what I distinguish as different above are  
> actually the same.. Some folks always viewed the function of the OSI  
> presentation layer context and protocol as being able to act as a  
> streaming filter - removing from the data stream items that the  
> recipient is not authorized to view - much like proxy firewalls do  
> today. For this reasons, one sees encryption formally modeled at the  
> layer 6 presentation layer to this day (so it can apply after  
> filtering/guarding by a P-layer "guard" proxy). This is obviously  
> somewhat contract to where encryption occurs in practice today  
> (layers 2-5 of the network [frame, packet/ipsec, fragment/ssl,  
> session/socks], or layer 7). That is, anywhere EXCEPT layer 6.
>
> If I think like Henry (for whom Id guess that presentation contexts  
> and syntax conversion of objects on the fly is normal set of design  
> concepts whether or not he is familiar with this terminology, one  
> could apply the layer 6 notion - where the act of applying access  
> control filters is performed by a custom presentation layer protocol  
> - one tuned to understand and apply the FOAF attributes in the  
> stream to-be-filtered. In todays web, none of this would ever be  
> performed by any class of network layer function - it would be a  
> private protocol that the FOAF subject and FOAF object engage in, as  
> articulated in the algebra of the data model and access control  
> attributes.
>
> If I hazard a guess, much of the architecture of xml dsig/enc should  
> apply nicely - where the primitive function is not encryption but  
> filtering of the set of internal objects within the FOAF file that  
> are being de-reference, by the controlling access rules in that same  
> FOAF file/stream. Add to that how Henry already uses rules in his  
> FOAF file to negotiate the presentation context (I mean "whether to  
> send N3 or xml/rdf"), one may already have a solid toolkit from  
> which to work on an network-focused access control model for FOAF  
> applications.
>
>> 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:// <http:///> ...
>>> Any thoughts on this?
>>
>> Is this FOAF specific? Or just a general thing with authenticated
>> views of Web sites.
>
>
> But to do this one will have
> to answer the problem of how to make some relations visible to some
> people and not to others. I know that a lot of people are happy to put
> their business information available online for all to see, but would
> rather not have everyone read their family relations. So if Facebook
> or LinkedIn are going to be able to publish foaf files we need make it
> possible for them to offer this functionality.
>
> The simple way to solve that problem is to return different
> representations to different people viewing a particular foaf file.

-------------- 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/20080113/5cbf38e3/smime.bin