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:

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