Re: [regrep] One RegistryObject - Many ACPs proposal

["Monica J. Martin" <monica.martin@sun.com>]

Could there be a dependency on another association that could affect the
preference that was used?

Thanks.

Chiusano Joseph wrote:

> I like this idea very much (of course).  I also prefer Beethoven. :)
>
> Regarding the following:
>
> <Quote>
> 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.
> </Quote>
>
> 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,
> etc.)
>
> Joe
>
> Farrukh Najmi wrote:
> >
> > While reviewing Joe's Web Service registration paper I encountered an
> > apparent mistake in how the paper suggested one associate an ACP with a
> > RegistryObject. The ebRIM 2.36 spec says that that a single ACP is
> > associated with a RegistryObject via its accessControlPolicy object. The
> > BP paper suggested using an Association instead.
> >
> > At first I was about to flag this as a mistake but then I realized that
> > this was a better way to assign an ACP to a RegistryObject because:
> >
> > -In many cases there would be no custom ACP. In current approach, there
> > would be a waste of accessControlPolicy attribute. Under the Association
> > approach no waste occurs.
> >
> > -In current approach, there can only be one ACP associated with a
> > RegistryObject. Under the Association approach multiple ACPs may be
> > associated with a RegistryObject.
> >
> > Proposed Changes To ACP
> > ------------------------
> >
> > -Drop accessControlPolicyAttribute attribute from RegistryObject
> >
> > -Define a new canonical associationType "AccessControlPolicyFor"
> >
> > -Define that zero or more ACPs may be associated with a RegistryObject
> > via an Associations where ACP is sourceObject and RegistryObject is
> > targetObject.
> >
> > -Define that when evaluating access control for a RegistryObject, The
> > following 4 sets of ACPs will be considered:
> >
> > 1. Default ACP for the Registry
> >
> > 2. User ACP
> >
> > 3. Submitting Organization's ACP (if any)
> >
> > 4. Responsible Organization's ACP (if any)
> >
> > 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.
> >
> > The result is that a very powerful ACP model that takes into account the
> > policies of all stake holder's in the RegistryObject. It also avoids
> > having to evaluate policies that have nothing to do with this object
> > (efficient).
> >
> > What do people think of this suggestion?
> >
> > Thanks to Joe for inspiring this idea. Reminds me that Mozart got it
> > right the first time ;-)
> >
> > --
> > Regards,
> > Farrukh
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>


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