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 with reference access control


Farrukh / Duane,

Hmmmm.

There's a third way - as I cannot frankly see people registering all
those associations - as there is zero ROI on that.

What if there was a way of automatically know who was
using what? A kind of use profile that automatically registered
what UBL transaction they are using, and what elements and
fields and rules apply?

Then you could use that to search and query on those
usage associations very easily instead.

So - OK - you guessed it - if they register their CAM template
for their UBL schema - then its automatic.

Better yet - since you would expect trading partners that are
sharing the same implementation profile - aka CAM template -
to just point to that - especially if they are registering their CPA
and context profiles - suddenly those 10,000 users reduce to
a few hundred CAM templates of their use profiles...

Cheers, DW.

----- Original Message ----- 
From: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>
To: "Duane Nickull" <dnickull@adobe.com>
Cc: <regrep@lists.oasis-open.org>
Sent: Thursday, May 06, 2004 12:27 PM
Subject: Re: [regrep] [Proposed Change] Replace Association confirmation
with reference 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?
> >>
> >
>
>
> -- 
> Regards,
> Farrukh
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>



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