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] [Proposed Change] Replace Association confirmation withreference access control


Duane Nickull wrote:

> 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.

I assume that above would be moving to XACML since that is the normative 
required way to handle access control?

>
> 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.

That is exactly what the current specs do. You should really read the 1 
page or so that I sent refernces to in original email.

>
> 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.

The crux of the debate is:

a) whether we treat associations special and different from other types 
of references

b) whether extramural associations should be managed via existing access 
control mechanisms (to prevent unauthorised access)
or whether it should be unrestricted (unilateral assertion) and then 
confirm (or not) and show confirmation state.

My premise is that we shoudl treat extramural associations the same as 
any other type of refrence and use XACML refrerence Access Control to 
decided who can or cannot create references.

I am curious if YDS ever implemented association confirmation. Anyone 
who has would know the current spec behavior better and would be very 
empathetic to the difficulties in implementation and use of current 
behavior ;-)

-- 
Regards,
Farrukh


>
> 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?
>>>>
>>>
>>
>>
>





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