Re: [regrep] [Proposed Change] Replace Association confirmation withreference access control

[Duane Nickull <dnickull@adobe.com>]

In the YDS implementation, we used a unix like model for hierarchical 
classification schemes.  If I own node "A", then only I can bestow 
permissions to other users to RWD nodes with "A" as a parent, directly 
or indirectly.

I can also lock my node from others making reference to it or even 
seeing it without my permission.

What I was getting at is that maybe requiring a blessing is not needed. 
 We simply allow unilateral assertions that "PartyA" says that their 
object "foo" is associated to "PartyB"'s object "bar" and make it 
visible whether B has responded or not.  That way, If B disagrees, he 
simply does nothing.

Unilateral associations are important to acknowledge as something that 
will happen.  It is unlikely that all users of a registry ecosystem will 
ever arrive at complete consensus.

Duane

Farrukh Najmi wrote:

> Duane Nickull wrote:
>
>> My opinion is that "who" makes the assertion is an essential part of 
>> the association.  Their views may not necessarily be 100% correct or 
>> agreed to by all parties since things like context of use can affect 
>> semantics. I would support that someone can make a unilateral 
>> assertion and we have a mechanism whereby a reciprocal association 
>> can be declared or agreed to.
>
>
> That is what we have right now (association confirmation). The point 
> is that the confirmation / unconfirmation and tracking confirmation 
> state is clumsy and very specific to associations. What about other 
> type of references other than associations (e.g. ClassificationNode 
> references to other ClassificatuionNodes as parents - meaning who can 
> extend my scheme etc.)
>
> Also confirming associations is an unsolicited burden on object 
> owners. It has also been difficult to implement.
>
> The solution I propose will work in all cases consistently and with 
> more expressivity and is simpler all around.
>
>>
>> One issue may be manageability.  Imagine UBL puts its schema into a 
>> registry and gets 50,000 people each asserting via associations they 
>> "use" certain objects.  The owner of UBL in that registry may not 
>> want the responsibility of having to respond to each and every case.
>
>
> That is one of the major issues with the current model. In the 
> alternative model I propose  the way things work is that I decide as 
> object owner  WHO I allow to reference my object and under what 
> circusmtances. Beyond that I never have to worry about  who is making 
> references. The old way requires me to give  my blessing on each  
> reference on a case by case bases. The new proposed way allows we to  
> specify the rules under which I allow refences and  from then on I do 
> not have to bother with  it.
>
>>
>> My $0.02
>>
>> Duane
>>
>>
>>
>> Farrukh Najmi wrote:
>>
>>>
>>> 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?
>>>
>>
>
>

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com