[foaf-dev] for more information please log in

Sun Jan 13 23:57:46 GMT 2008

Classically, one denotes in the access control lists borne by objects (of which there are typically several in a FOAF file) indicate the access modes to that object, given identification of the subject user. In variants supporting different authentication "strengths", the activation of the rule is gated on the subject performing the identication and authentication at the required strength (or better).

so... if object X in a foaf file has attributes declaring

mode=read, strength=identity, scope=self, then one can read the object itself by *merely presenting an identity* (un-authenticated)

mode=read, strength=openid:pap:2factor, scope=list, then one can read the object itself and its relationship attributes by merely presenting an identity (as authenticated by openid asserting pap level "2factor"*

mode=read&compose, strength=openid:pap:2factor, OP=#myOP, scope=list, then one can read the object itself and its relationship attributes  *and their values from this access point* by merely presenting an identity (as authenticated by openid pape level 2factor), as attested to by the OP known locally by the name #myOP

Of course, #myOp might imply strength=openid:pap:2factor to any object that references this op.

(Lets also not forget that the ability to read all the acls is itself MAY be controlled by an acl, that may require that a certain strength of the I&A and certain policy domains (OPs) are asserted, before the object/attribute-level acls are released.

We should now address the point: how does one know if its worth bothering with authentication at the requested strength to get more  info?

Several answers:

1. if your recognize yourself (as subject) as being a member of one of the object's declared policy domains (OPs), you presumably know that all member of that OP are interested in fish. Therefore, perform authentication at strength S to get additional fish-related relationship records.

2. if the nature of certain dinvidiual attributes would require individual accountability (and thus authenticated identity), then authenticate to show good citizenship (e.g. access a non-masked email address, say). This implies that the acls above act at the attribute(s) level, rather than the object class.

3. some of the normally-denied sub-objects within the PPD have their identities declared publicly by the PPD, where their schema names denotes the type of info you might be interested in viewing - should you up the strength of your I&A. Again, the local copy of the schema defintion of those sub-objects might codify the I&A strength requirements to avoid listing them on each acl entry.

For all of the above, one use non acl mechanisms too L one can use lattice-based policy enforcement rather than acls to enforce the same rules - allowing for more "non-discretionary" polices concerning info release. Distinguishing between discretionary and non-discretionary formulations of the policies address just who is more in "control," on a sliding scale: the user, the releasing organization, the info owner, the security authority, etc. FOAF would ideally distinguish itself from openid ...and not limit itself to user-centric control paradigms.

________________________________

From: Story Henry [mailto:henry.story at bblfish.net]
Sent: Sun 1/13/2008 2:58 PM
To: Peter Williams
Cc: foaf-dev
Subject: Re: [foaf-dev] for more information please log in

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:///>  <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.