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




In my mind I have 'reserved' the use of 'assertion' for 'core component
building' thus being a key part of 'Context Declaration' ...
acknowledged it would be useful to state who (and their role) formed any
(& all) 'object association cum classification'  ... is it not  better to
leverage the policies & rules structures of XACML to establish how this
should be done ?


<quote who="Duane Nickull">
> 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.
>
> 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.
>
> 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?
>>
>


-- 
Carl Mattocks

co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
co-Chair OASIS Business Centric Methodology TC
CEO CHECKMi
v/f (usa) 908 322 8715
www.CHECKMi.com
Semantically Smart Compendiums
(AOL) IM CarlCHECKMi


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