OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [regrep] One RegistryObject - Many ACPs proposal

Chiusano Joseph wrote:

>I like this idea very much (of course).  I also prefer Beethoven. :)
>Regarding the following:
>We need precedence rules for how the 4 sets play together. On this last 
>point I am thinking some more and discussing with some experts.
>Perhaps we can weave in the idea of Preference Indicators for
>associations, as in my last message.  This would allow one to simply
>indicate a hierarchy of preference based on their own criteria (which
>may involve preference of the SO's ACP over the RO's ACP, or vice-versa,
Uday and I spoke at length with Seth Proctor who is the lead for Sun's 
XACML open source implementation about how to define precedence rules 
defining how the 4 sets (Registry, User, SO, RO) of policies play together.

His suggestion was to simply use XACML and its combiningAlgorithm 
capabilities. The upshot of the discussion is that we should have 
exactly one XACML PolicySet for a RegistryObject (the way things are 
today) and allow that PolicySet to compose by reference, any/all of the 
Policy/PolicySet from the 4 sets (Registry, User, SO, RO). This allows 
the creator of the ONE super PolicySet to:

1. Define a tree where each node is a Policy or PolicySet belong   to 
one of 4 sets (Registry, User, SO, RO)

2. decide precisely what combiningAlgorithms (denyOverrides, 
permitOverrides, onlyOneApplicable, firstApplicable, or even a custom 
one) to use when combining the policy decisions from sibling nodes at a 
given level in the tree.

The result is maximum flexibility.

Given this information we have two choices:

1. Retain our current accessControlPolicy attribute in RegistryObject

2. Allow a RegistryObject to have zero or one ACP associated with it via 
an Association. More efficient storage wise.

I would recommend (2) which means we do all the changes I proposed in 
this thread but with the constraint that there will be only one node 
associated with a RegistryObject. If there are more than one then most 
recent one would be used.

Does this sound reasonable closure on this issue?

BTW in case you are wondering how come all these issues popping up 
now... As Nikola and I are wrapping up the final details on XML Schema, 
Filter Query, SQL schema etc. , we are finding little fit and finish 
issues. Rather than batching the issues fo the next meeting we are 
trying to get them resolved via email so we can reach closure on the 
spec work.


To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]