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: [Proposed Change] Replace Association confirmation with referenceaccess control



I am working actively on the 2.9 spec (precursor to 3.0). In version 2.5 
and earlier we have a concept of
Association Confirmation as defined in section 8.6 of ebRIM 2.5. The 
idea is that in an extramural association
(association between objects owned by different parties) if I create an 
association with someone else's object
they MUST confirm that association in order for it to be fully valid. 
There are clumsy ways to confirm and
unconfirm an extramural Association described in 8.6.2 and 8.6.3.

In version 2.9 we will add clarifications to the XACML feature to define 
precisely how fine grained access
control can control WHO gets to REFERENCE a RegistryObject and under 
what circumstances. The WHO is
the Subject, the REFERENCE is the Action and the RegistryObject is the 
resource.

For example you will be able to define an ACP that say:

I allow a reference to my object to be created only if all the following 
conditions are met:

a) The subject making the reference has role "ProjectLeader"

b)  that reference is from an Association instance

c) the reference is being made via the sourceObject property of Association

d) the value of the associationType attribute in association identifies 
the "Supercedes" associationType

Given this powerful and flexible capability it seems very clumsy and 
unnecessary to have the
existing Association confirmation feature.

I would like to propose that we remove Association Confirmation feature 
and instead leverage the
reference Access Control feature to control who can create an extramural 
association to someone else's
objects. This simplifies the spec greatly and can also be another 
example where our specs use a few
good primitive features to support higher level features or requirements.

Thoughts?

-- 
Regards,
Farrukh




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