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

Farrukh Najmi wrote:

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

Yes - XACML is the implementation of the policy although I cannot 
confirm or deny that is what Adobe is officially doing since this is 
private information ;-)

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

Apologies - I misread it today (actually an older version).

>> 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 ;-)

We implemented it to allow anyone to make a unilateral declaration.  IT 
was implied that only those who have write privileges on the source 
object caould make such assertions.  There was no requirement for the 
owner of the target to even confirm or acknowledge the assertion was 
made, although they could see that it was there.  

I would vote to allow unilateral, unacknowledged associations, then 
allow the target object owner to acknowledge it as an aoptional step OR 
make a reciprocal assoiation. The reciprocal association should not 
automatically agree with the original association.


A declares it loves B, but B does ot agree and B can hide its' object 
from A and remove or prevent such declarations.
A declares it loves B, but B does not acknowledge this nor does B refute 
this declaration.
A declares it loves B, and B acknowledges this declaration exists.
A declares it loves B, and B acknowledges this declaration and agrees 
that it is valid, but does not make a reciprocal declaration.
A declares it loves B, and B acknowledges this declaration exists and 
also declares that B loves A.
A declares it loves B, and B acknowledges this declaration exists, but B 
declares that it hates A.

That way all use cases are satisfied.


Senior Standards Strategist
Adobe Systems, Inc.

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