OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: RE: [xacml] Multiple obligations


> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Friday, June 10, 2011 1:26 PM
> To: Sinnema, Remon
> Cc: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Multiple obligations


> I think the rationale has been to avoid having to explicitly talk about
> obligations in each combining algorithm description. I don't like the
> way it is now. A better way to define it would be that each combining
> algorithm specification explicitly specifies which obligations are
> returned.

I think I agree with you.

> As you say, probably the most meaningful way in most cases would be
> that
> we should view it such that there is ultimately a single leaf rule
> which
> "caused" the decision and obligations would come only from the path to
> this rule. In section 7.16 it says "If the PDP's evaluation is viewed
> as
> a tree of rules, policy sets and policies, each of which returns
> 'Permit' or 'Deny', then the set of obligations and advice returned by
> the PDP to the PEP will include only the obligations and advice
> associated with those paths where the effect at each level of
> evaluation
> is the same as the effect being returned by the PDP." This was perhaps
> intended to mean it.

That doesn't say whether the obligations of *all* such rules MUST be returned.

> Things get more complicated if the combining algorithms do more than
> simple conflict resolution between policies, like for instance majority
> voting for the decision, in which case there would be more than one
> rule
> which "caused" the decision.

I hadn't considered that possibility. I agree that that complicates things.

> All these cases would be easily defined on a case by case basis for
> each
> algorithm if the collection of obligations is specified in the
> combining
> algorithms rather than it's own section in the specification. For each
> algorithm we can include those obligations which make sense from a use
> case perspective, which would be to be collect those obligations to
> which belong to rules and policies which impacted the decision, not
> those which were later overridden.
> The case where there are more than one rule which actually could have
> caused the decision is more open in terms of what makes sense. that's
> what the obligation families working draft tries to address in part at
> least.

I was not aware of this effort, thanks for pointing it out. I will take a look.


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