[foaf-dev] for more information please log in

[Peter Williams]

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.