[foaf-dev] for more information please log in

Peter Williams pwilliams at rapattoni.com
Mon Jan 14 09:44:14 GMT 2008

Lets address the application of the bloom filter to access control in specifically a FOAF setting:-

If we assume that one authenticates optionally and only for a purpose that is FOAF-specific (i.e. FOAF is not a general purpose cache of distributed directory data, but targets the assertion of personal friend relationship and personal expectations of privacy) then authentication exists to assert friendship in order to obtain friendship privileges in accordance with the limits of the class of friendship/acquaintance.

If the bloom filter allows one to test whether one is probably a member of the FOAF-object's friend/acquaintaince list with the implied right of the FOAF-subject to query private friendship relations,  lets now assume that authentication exists to now (1) "assert" that status seeking a session; and a resulting login  should then (2) "entitle" one to exploit various query rights about the subject's and others' relations with the person whose PPD is being addressed.

Upon login with strength S, the authorization cookie assigned to the FOAF-subject's web session will be assigned various access mode rights as a function of S and after the session manager possibly tests additional bloom filters that guard whether you the subject ought to be assigned privilege P - where Pi compute particular classes of friend-based inferences. For example, strength S of "publickey" may gate access to inference about the pubkeys of Henry's friends. If strengh S' is "openid from provider #myOP", then this may gate query rights to the pubkeys of Henrys friends whose openids are asserted by #myOP. In general S => P.

So, in one embodiment, std xml encryption would be applied as the entire FOAF file as is being streamed out by the webserver hosting the FOAF file, where those query rights would identify which (syntactic) elements of the xml/rdf should be masked. Those parts of the stream that should be masked for the particular FOAF subject UA would be encrypted using std xml element selection principles built into the xml encryption transform. The various groups of parts identified udner the transform would each be encrypted using a particular key generated now for this purpose - a key which could subsequeently be shared with those doing authorized FOAF file aggregation of particular classes of relations that the PPD owner select, when removing his/her expecation of privacy.

Ignoring my fanciful embodiment, have I got the general thrust of the idea?

More information about the foaf-dev mailing list