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
