RE: [higgins-dev] Proposed update to higgins.owl (aka HOWL)

[David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx>]

Paul, 

I wanted to ask more about the support
for scope level 3.   Is node-entity limited to self?   I consider
"Self" to be type of role that is dynamically or heuristically
assigned at the time of the policy evaluation.  Other types on relationships
need to be considered.  What may be needed is something like xxxByRelationship
<list of relationship types>, where Self is a specialized relationship
type.  I should be able to express an access control statement where
only the employee's manager can update the salary attribute. If the employees
node has a relationship attribute with the type of isManager with the value
containing the accessing Entities' node (i.e. the Manager), then let the
accessing entity modify the salary attribute.       
Thanks, 

David 

David Kuehr-McLaren

"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

02/23/2008 01:05 PM

Please respond to
"Higgins \(Trust Framework\) Project developer discussions"        <higgins-dev@xxxxxxxxxxx>

To	"'Higgins \(Trust Framework\) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
cc
Subject	RE: [higgins-dev] Proposed update to higgins.owl (aka HOWL)

Jim,

I agree with your statement of the requirements. We need to be able to
add
access control statements at these four levels of scope:

 1) Global: attribute definition. All values of all attribute instances.

 2) Context: attribute definition as used in a specific context. All
    values of all instances of an attribute in the containing
context.

 3) Node-Entity: <explained below>. All values of all instances of
    an attribute by the Entity that this Node represents.

 4) Node: all values of an attribute on a single Node instance

I *intended* to support levels #1, #2 and #4 in the HOWL update proposal
here [1] [e.g. you'll notice for example that "higgins:accessControl"
property has an unspecified domain, this would allow it to be attached
to an
attribute/property type definition, or to something else.]. These were
supported by the modifyBy, getBy, deleteBy, addBy primitives.

I also added support for level #3 using the {modify|get|delete|add}BySelf
primitives. This is the common case where Node N1's context is authenticated
to by Entity E1 (aside: see how useful having two different words is!)
AND
that N1 is a partial representation of E1. 

For example, where Jim is trying to edit the emailAttribute of the Node
that
represents Jim, and Paul is trying to edit the email attribute of the Node
that represents Paul, etc. We have a simple way of handling this case
without having to explicitly put Jim, Paul, Bob, etc. on specific node
instance access control lists. To allow modification we make this one
statement about the emailAttribute:

    emailAttribute modifyBySelf true

I will write all of this up on the wiki prior to our telecon on this subject
next week. I also see a way to improve on [1] to make all this scope stuff
clearer, and I'll get that done as well.

-Paul

[1] http://wiki.eclipse.org/HOWL_Update#Access_Control_Primitives 
________________________________________
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Friday, February 22, 2008 9:17 AM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: Re: [higgins-dev] Proposed update to higgins.owl (aka HOWL)

If I'm reading the higgins.owl correctly, it seems like the stab at access
control is to allow one to put access control statements on model elements.
 For example, say we have a model element for the "homeAddress"
attribute.
 One could control write access to the "homeAddress" attribute
by placing
upon its model element an "addBy" specifier which names the node
identifier(s) that are allowed to write to instances of that attribute.

So, (I've said this before) I worry that this is so inadequate that it
will
only serve to frustrate people.  It only works on the global scale
-- I
can't control access to attributes on a per-node instance level.  In
other
words, I can't say that my manager has write access to my "salary"
attribute. without granting him the same access to *everyone's* salary
attribute. 

If instead (and this is only one suggestion) we allowed access control
statements to be made on the resources they apply to, we could apply them
to
specific instances of things.  This wouldn't preclude us from making
global
statements.  That could be done by allowing access control made on
the
Context instance to apply globally within the context.  I'm sure there
are
even better ideas than this. 

Jim

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
02/20/08 4:43 PM >>>

Attached is a proposed update to higgins.owl along with two example files.
I’m keeping this out of the SVN until the 1.0.0 branch is done. The changes
are summarized here: http://wiki.eclipse.org/HOWL_Update. Other than endless
refactoring to align what we’re doing with best practices and other
standards related to RDF, it includes experimental support for a proposed
simple access control policy _expression_. 

  

I have also attached a sample test person.owl ontology that a CP might
use,
and an example of simple instance data here: person-example.owl. 

  

[Sergey this is the update that I mentioned I was working on today] 

  

-Paul 

  

  

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev