RE: [xacml] Multiple obligations

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

I agree that the core spec should be improved with respect to obligation-combining.

But I'm not sure now is the time to do it unless we want to delay 3.0 indefinitely.  We don't have any good use cases or requirements around obligation processing (unless there are some from the 2.0 days), so we would spend some time digging up use cases and requirements before we could consider design options.

A purely mathematical approach that only considered possible collections of obligations would probably not meet any business needs.  One goal of the design should be to reduce the indeterminacy as much as possible so the policy writer can predict what obligations/advice will be returned from a given request context.

I'm not sure we should tie obligation-combining with policy- or rule-combining, since they are really orthogonal concerns.  An alternative design would be to define obligation-combining algorithms that can be specified by the policy writer.  These algorithms would reduce the set of candidate obligations/advice to an actual return set.  I haven't thought this out completely.

Regards,
--Paul

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Tuesday, June 07, 2011 04:50
> To: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Multiple obligations
> 
> Hi all,
> 
> The "proper" way to fix this would be to explicitly include obligation
> processing in each combining algorithm, rather than having it on the
> side in a different section, saying that obligations from any policy
> "which is evaluated" is included.
> 
> In my opinion it would be worth fixing this.
> 
> Best regards,
> Erik
> 
> On 2011-06-06 14:59, rich levinson wrote:
> > Hi Ray/TC,
> >
> > I agree, I don't like it either, which is why I wanted to state it
> > explicitly so
> > we all know what the current behavior implies, at least based on my
> > reading of the text to date.
> >
> > My statement was that is how I understand the current operation
> > to be, although it is not clearly and unambiguously stated in the
> text.
> >
> > However, I am not sure what other option might be inferred from the
> > text, although your suggestion sounds like a reasonable alternative,
> if
> > we were to explicitly state it that way.
> >
> > In any event, once the current behavior is clarified, then whatever
> > it is can be considered the default option, and for 3.0, at least, if
> > devs
> > want to offer other options then they can be custom w combiner
> > parameters, which is what would be explained in the implementers/
> > policy designers guide - explained so designers would know what to
> > look for and devs would know what to implement.
> >
> >     Thanks,
> >     Rich
> >
> >
> > On 6/6/2011 5:27 AM, remon.sinnema@emc.com wrote:
> >> All,
> >>
> >>
> >>> -----Original Message-----
> >>> From: rich levinson [mailto:rich.levinson@oracle.com]
> >>> Sent: Friday, June 03, 2011 12:52 AM
> >>> To: xacml
> >>> Subject: [xacml] Minutes for 2 June 2011 TC Meeting
> >> [...]
> >>
> >>>     Obligations/Advice combining ambiguities. (dependent on final
> >>>      version of combining algorithms)
> >>>      http://lists.oasis-
> open.org/archives/xacml/201105/msg00094.html
> >>>
> >>>       rich: working assumption is that in deny-overrides that if
> there
> >>>     are multiple permit rules then all the applicable permits
> >>>     add their obligations to the response if decision is permit,
> >>>     as opposed to the deny decision, where only one rule's obls
> >>>     are returned.
> >>>
> >> I'm not sure I like this. First of all, this means there is an
> >> asymmetry between the permit and deny cases, as noted on the call.
> >> Secondly, this assumption rules out the following performance
> >> improvement: For deny-overrides, once an applicable permit rule has
> >> been found, other permit rules don't need to be evaluated, since
> they
> >> can never change the decision.
> >>
> >> Thanks,
> >> Ray
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php